From pcn-bounces@ietf.org Thu Aug 02 10:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGc24-0004t0-9D; Thu, 02 Aug 2007 10:52:08 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IGc23-0004sv-FY for pcn-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 10:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGc23-0004sn-4b for pcn@ietf.org; Thu, 02 Aug 2007 10:52:07 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGc21-0001pX-GQ for pcn@ietf.org; Thu, 02 Aug 2007 10:52:07 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l72EtarU018009 for ; Thu, 2 Aug 2007 09:55:36 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 09:52:03 -0500 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 09:52:03 -0500 From: Steven Blake To: pcn@ietf.org Content-Type: multipart/mixed; boundary="=-iWumQdZ3bf5kDA7s20d7" Date: Thu, 02 Aug 2007 10:52:03 -0400 Message-Id: <1186066323.3386.44.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 02 Aug 2007 14:52:03.0913 (UTC) FILETIME=[B069BB90:01C7D514] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Subject: [PCN] PCN IETF 69 Meeting *DRAFT* Minutes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --=-iWumQdZ3bf5kDA7s20d7 Content-Type: text/plain Content-Transfer-Encoding: 7bit PCN, Here are the draft minutes for the PCN meeting held last week in Chicago. Many thanks to Bruce Davie for taking notes during the meeting. Please send comments/corrections to the list in the next week. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-iWumQdZ3bf5kDA7s20d7 Content-Disposition: attachment; filename=pcn-ietf69-minutes.txt Content-Type: text/plain; name=pcn-ietf69-minutes.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion & Pre-congestion Notification (PCN) Working Group ** DRAFT ** Meeting Minutes IETF 69 - Chicago July 25, 2007 9:00am-11:35am CDT Meeting minutes taken by Bruce Davie Chairs - Scott Bradner & Steven Blake o Administrivia The agenda was presented and the order of two presentations (dratf-chan-pcn-encoding-comparison-00 and dratt-westberg-pcn-load-control-00) were switched. The working group milestones from the charter were reviewed. Steve Blake suggested some questions participants should ask about assumptions made in the various approaches (see slide). o Phil Eardley: Pre-Congestion Notification Architecture draft-eardley-pcn-architecture-00.txt Aiming to make this a WG draft to meet the 1st milestone (info RFC) includes broad set of authors Draft aims to be compatible with many approaches to marking and edge behaviors> Numerous comments have been received requesting clarifications on terminology, scope, design goals, deployment scenarios. Need to add: - single marking is OK - tunneling discussion - addressing - probing & ECMP OAM needs review - Tom Taylor will comment by end of week Tina Tsou will send some OAM comments to the list David Black points to RFC 2983 - Diffserv & Tunnels Bob Briscoe mentions ECN tunneling in 3168 and a new draft (draft-briscoe-tsvwg-ecn-tunnel-00.txt) on ECN tunneling - he will help with text for PCN arch. Anna Charny on terminology 4th option - naming could be based on semantics rather than function. Kwok Ho-Chan Supports Anna's view. Anna Charny suggests - "upper" and "lower" threshold. Joe Babiarz - suggests we move on. Georgios Karagiannis - supports Anna. Bruce Davie asked for show of hands to see if there is broad support for upper/lower - yes, there is. Tina Tsou - Does ingress need to know address of centralized node? Steve Blake says there is no centralized node. Anna Charny - current draft does include concept of central node. Tom Taylor - central node has benefits; "quicker" solution. Joe Babiarz- should focus on determining ingress and egress nodes for a flow Bob Briscoe - trying to address how PCN can fit into existing systems that have a central PDP. Kwok Ho-Chan - central PDP a deployment scenario for future consideration. Lars Eggert (TSV AD) - charter is clear in that egress should be able to make decision. Bob Briscoe - some proposals have ingress making decision. Georgios Karagiannis - PCN should not focus on finding address of central node. Lars Eggert - would like to avoid mismatch between devices that must be centralized and devices that must work at egress. Steve Blake - ECMP handling has implications on flow state. Bob Briscoe - when a node fails, we know it will cause problems in ECMP - would be effectively like no PCN. Anna Charny - worst case is bad - should look at some real data. Joe Babiarz - there is a valid proposal for ECMP treatment. Scott Bradner - show of hands - working group document? strong support by the meeting participants. There are too many authors, if all are contributing then select editor and put rest of names in acknowledgements section else if only a few are contributing have them as authors but do not use list of authors to indicate support. o Kwok Ho-Chan: Pre-Congestion Notification Encoding Comparison draft-chan-pcn-encoding-comparison-00.txt Survey, establish criteria for comparison, assist selection. Bob Briscoe - question about number of states - seems to be one too many. Issues - What's the relation between Functional Features and States? Plan to update draft to replace "feature" with "state". Bob Briscoe - Admission marking is a toggling between 2 states. Steve Blake - What is the intent of ADs for this document? Lars Eggert - Goal: explain how to shoe horn the needed signals into the few bits, discuss interactions with other uses (e.g. DSCP). Maybe this draft is too early? Kwok Ho-Chan - Algorithm drafts are trying to be encoding independent. Lars Eggert - Once you know what needs to be conveyed, then figure out how to encode it. Bob Briscoe - Some schemes use more code points than others, and there may be tradeoffs. Lars Eggert - agrees, maybe premature to look at encodings in this level of detail. Georgios Karagiannis - Should we delay this draft? Lars Eggert - Feel free to work on it if you have time to burn. But how useful is it? List of candidate algorithms might be shorter after this meeting. Anna Charny - Some complexity might be avoided. We know how many states in each algorithm. Maybe should focus on how to encode the right number of states. Kwok Ho-Chan - The evaluation criteria are the important part of the draft - please give input. Francois le Faucheur - One approach is to identify the number of code points for a given approach and then discuss how to encode them - will you do this in -01? Kwok Ho-Chan - -01 will be much shorter, Still plans to say what the bit patterns mean. Lars Eggert - If it doesn't matter what info is in what bit, then can just talk about the number of bits, not what they mean. Bob Briscoe - the one reason why it matters is tunnels. Phil Eardley - suggest structuring draft as: If you want n states, here are your options. Anna Charny - For all proposals, it doesn't matter what bits encode what states. How to encode the number of states is what matters. Steve Blake - Asks authors for another revision before WG adoption. Kwok Ho-Chan - Can we make that decision on the mailing list? Still want to meet the WG milestone. Steve Blake - All WG decisions are made on the mailing list. Will send out a call for comments. o Georgios Karagiannis: LC-PCN - The Load Control PCN Solution draft-westberg-pcn-load-control-00.txt Phil Eardley - Are you using the same bit marking to indicate both congestion and severe congestion? Georgios Karagiannis - Yes. Phil Eardley - So, does the rate at which you mark packets change? Georgios Karagiannis - No. Phil Eardley - Marking rate seems to drop as congestion gets worse. Georgios Karagiannis - There are other things going on beside what is shown in the presentation (!!) Phil Eardley - Must Admission control use probing? Georgios Karagiannis - Yes. Anna Charny - There are some things that don't seem right, can they be fixed in the next version? Georgios Karagiannis - Yes, but maybe not before September. o Anna Charny: Pre-Congestion Notification Using Single Marking draft-charny-pcn-single-marking-02 Performance Evaluation of CL-PHB Admission and Termination Algorithms draft-zhang-pcn-performance-evaluation-02 High level comparison of Virtual Queue (VQ) and Single Marking (SM) admission. SM is sensitive to bursts at low aggregation, and over-admits More brittle than VQ when number of flows is in the 1-2 range. Both schemes unfair to long-haul aggregates in the multi-bottleneck case. Bob Briscoe - Unfairness to long flows a feature, not a problem? Anna Charny - It's really quite bad. Steve Blake - Is the effect at low aggregation levels really a problem? Assume large aggregation. Anna Charny - There may be cases where it is a problem, because there are many flows at bottleneck but some I-E flows are not highly aggregated. Bob Briscoe - And that might lead to picking one scheme vs. another. Beat down of long flows with multiple bottlenecks - needs large demand for long period - probably of limited practical impact. David Black - This looks like congestion collapse - goal should be get out of this state. Anna Charny - It's hard to do in this case. There is a constant demand that considerably exceeds the capacity Summary: Both schemes work well in most cases, the salient difference being when small number of flows make up some ingress-egress aggregates. Francois le Faucheur - The SM scheme uses a metering scheme that already exists in routers. o Joe Babiarz: Three State PCN Marking draft-babiarz-pcn-3sm-00 Tom Taylor - Slowdown parameter - is it the same for all nodes? Joe Babiarz - Does not need to be constant - variation affects termination rate; it's a configured parameter. o Jozef Babiarz: Simulation Results for 3sM draft-babiarz-pcn-explicit-marking-01 Tina Tsou - What is the service class BW limit? Joe Babiarz - It's the amount of BW available in the router to forward that class without loss. Bob Briscoe - See his other draft in tsvwg on small/big packets draft-briscoe-tsvwg-byte-pkt-mark-00.txt. --=-iWumQdZ3bf5kDA7s20d7 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://www1.ietf.org/mailman/listinfo/pcn --=-iWumQdZ3bf5kDA7s20d7-- From pcn-bounces@ietf.org Fri Aug 03 13:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0rZ-000757-J7; Fri, 03 Aug 2007 13:22:57 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IH0rY-0006z8-3y for pcn-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 13:22:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0rX-0006wX-Lt for pcn@ietf.org; Fri, 03 Aug 2007 13:22:55 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH0rX-0000sJ-7f for pcn@ietf.org; Fri, 03 Aug 2007 13:22:55 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 18:22:54 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Aug 2007 18:22:53 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37D@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN terminology Thread-Index: AcfVIbJKJXKTw21XRJWTQfwzZCBV3wA0J7pg From: To: X-OriginalArrivalTime: 03 Aug 2007 17:22:54.0253 (UTC) FILETIME=[ED3FC5D0:01C7D5F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Subject: [PCN] PCN terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0254520760==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0254520760== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D5F2.ECAA4BCC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D5F2.ECAA4BCC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I'm starting to do the mods in order to create draft-ietf-pcn-architecture-00, based on draft-eardley-pcn-architecture-00. =20 One of the things is to adapt the PCN terminology. The consensus at the WG in Chicago was to move to names that are more 'neutral' and to use names for marking that reflect how the marking is done (rather than what it is trying to achieve). I think that PCN-upper-rate & PCN-lower-rate, and threshold-marking and excess-rate-marking were mentioned.=20 =20 A copy and paste of the definitions isn't quite possible, are the following are OK? I also tried to take account of Bob's review comment (25 july on the list) that we shouldn't use "rate" in the definitions loosely.=20 * PCN-lower-rate: a reference rate configured for each link in the PCN-domain, which is lower than the PCN-upper-rate. It is used by an algorithm that determines whether a packet should be PCN-marked with a first encoding * PCN-upper-rate: a reference rate configured for each link in the PCN-domain, which is higher than the PCN-lower-rate. It is used by an algorithm that determines whether a packet should be PCN-marked with a second encoding.=20 * Threshold-marking: a PCN-marking algorithm such that all PCN-traffic is marked if the PCN-traffic exceeds a particular rate (either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the intent of the algorithm rather than its instantaneous behaviour, since the rate measured at a particular moment depends on the algorithm, its implementation and the traffic's variance as well as its rate * Excess-rate-marking: a PCN-marking algorithm such that the amount of PCN-traffic that is PCN-marked is equal to the amount that exceeds a particular rate (either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the intent of the algorithm rather than its instantaneous behaviour, since the rate measured at a particular moment depends on the algorithm, its implementation and the traffic's variance as well as its rate * PCN-marking: either threshold-marking or excess-rate-marking {if necessary we can define: PCN-lower-rate-marking and PCN-upper-rate-marking} I'll remove the term ECN-marking, which is unnecessary. =20 What do you reckon? Best wishes, phil =20 =20 ------_=_NextPart_001_01C7D5F2.ECAA4BCC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m starting to do the mods in order to = create draft-ietf-pcn-architecture-00, based on = draft-eardley-pcn-architecture-00.

 

One of the things is to adapt the PCN = terminology. The consensus at the WG in Chicago was to move to names that = are more ‘neutral’ and to use names for marking that reflect how the = marking is done (rather than what it is trying to achieve). I think that = PCN-upper-rate & PCN-lower-rate, and threshold-marking and excess-rate-marking were mentioned.

 

A copy and paste of the definitions = isn’t quite possible, are the following are OK? I also tried to take account of = Bob’s review comment (25 july on the list) that we shouldn’t use “rate” in the definitions loosely. 

·        PCN-lower-rate: a reference rate configured for each link in the PCN-domain, which is = lower than the PCN-upper-rate. It is used by an algorithm that determines = whether a packet should be PCN-marked with a first encoding

·        PCN-upper-rate: a reference rate configured for each link in the PCN-domain, which is = higher than the PCN-lower-rate. It is used by an algorithm that determines = whether a packet should be PCN-marked with a second encoding.

·        Threshold-marking: a PCN-marking algorithm such that all PCN-traffic is marked if the = PCN-traffic exceeds a particular rate (either the PCN-lower-rate or PCN-upper-rate). = NOTE: The definition reflects the intent of the algorithm rather than its instantaneous behaviour, since the rate measured at a particular moment = depends on the algorithm, its implementation and the traffic's variance as well = as its rate

·        Excess-rate-marking: a PCN-marking algorithm such that the amount of PCN-traffic that is = PCN-marked is equal to the amount that exceeds a particular rate (either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the = intent of the algorithm rather than its instantaneous behaviour, since the rate = measured at a particular moment depends on the algorithm, its implementation and = the traffic's variance as well as its rate

·        PCN-marking: either threshold-marking or excess-rate-marking

{if necessary we can define: PCN-lower-rate-marking and PCN-upper-rate-marking}

 I’ll remove the term ECN-marking, = which is unnecessary.

 

 What do you reckon?

Best wishes,

phil

 

 

=00 ------_=_NextPart_001_01C7D5F2.ECAA4BCC-- --===============0254520760== 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://www1.ietf.org/mailman/listinfo/pcn --===============0254520760==-- From pcn-bounces@ietf.org Fri Aug 03 14:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH1aQ-00011j-4h; Fri, 03 Aug 2007 14:09:18 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IH1aO-00011d-LJ for pcn-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 14:09:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH1aO-00011V-Ax for pcn@ietf.org; Fri, 03 Aug 2007 14:09:16 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH1aN-0002Oj-U1 for pcn@ietf.org; Fri, 03 Aug 2007 14:09:16 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 19:09:14 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Re: How to discuss WG scoping decisions in an RFC? Date: Fri, 3 Aug 2007 19:09:14 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37E@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <46A7144B.1010503@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: How to discuss WG scoping decisions in an RFC? Thread-Index: AcfOnJ3naTtn42eBQT2eDBvh0vhTtAHXF4GA From: To: , X-OriginalArrivalTime: 03 Aug 2007 18:09:14.0869 (UTC) FILETIME=[66A01A50:01C7D5F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael & Steve said: > > Regarding emergency use: the charter says: > > > > (D) flows may have different precedence, but the applicability > > of the PCN mechanisms for emergency use (911, GETS, WPS, > > MLPP, etc.) is out of scope > > > > This could be interpreted in more than one way, but I interpret this as > > saying that PCN-specific mechanisms will not take flow precedence into > > account. Which is a different than saying that PCN cannot be used with > > flow setup protocols/mechanisms that take flow precedence into account. > > >=20 > As soon as we have multiple PCN classes it might be useful to think > about flow precedence especially with regard to admission and > termination priority. Equal treatment of flows means that a highly > critical telemedicine application has the same probability to be > terminated as a "relatively" uncritcical VoIP call in case of a > disaster. I read the passage in the way that it's not our job to define > mechanisms for emergency use, but it is not prohibited to extend PCN > towards multiple classes with different requirements although this is > not the first thing to do. The conclusion I take from this is that the Architecture doc Assumptions section should just repeat what the Charter says. Any objections? Thanks, phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 03 14:32:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH1xL-00074w-Ka; Fri, 03 Aug 2007 14:32:59 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IH1xJ-00074r-Lp for pcn-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 14:32:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH1xJ-00074j-A3 for pcn@ietf.org; Fri, 03 Aug 2007 14:32:57 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH1xI-00035t-8l for pcn@ietf.org; Fri, 03 Aug 2007 14:32:57 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 19:32:16 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions Date: Fri, 3 Aug 2007 19:32:16 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64651175461B@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & ECN-(congestion experienced) interactions Thread-Index: AcfOTJNiDbXXskhTRKOfZp0Z2OHPEQBTiysXAAqlRpAABNx3KQAKhgHQAX4Tq5A= From: To: , X-OriginalArrivalTime: 03 Aug 2007 18:32:16.0781 (UTC) FILETIME=[9E4F23D0:01C7D5FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, you've persuaded me that your approach is better. I suggest we add text along the lines of your second Option (the first assumes a particular mechanism /encoding is chosen). Ie add (probably to end of Section 4): If a packet that is part of a PCN-flow arrives at a PCN-ingress-node with its CE (Congestion experienced) codepoint set, then we assume that the PCN-ingress-node drops the packet. There are lots of other possible behaviours that could be explored, but this assumption has the merit I think of being simple and sound (ECN-friendly) - and means we don't expend effort devising something cleverer (at least until we've finished doing the initial pcn charter).=20 Everyone happy - or at least not too unhappy? phil > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: 27 July 2007 06:15 > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions >=20 > See below. >=20 > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: July 26, 2007 7:34 PM > To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org > Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions >=20 > joe > sorry i explained it badly, let me have another go. > The scenario i was thinking of is this. We have a source sending data to > a receiver. somewhere in the middle between the Sx & Rx is a PCN-domain. > The traffic being sent is treated as PCN-traffic inside the PCN-domain > ie put into the PCN Diffserv class. However, between the Sx and > PCN-domain the traffic is treated in a class that can be ECN-marked. > When the traffic reaches the Rx, should any ECN-marking (that happened > before the PCN-domain) be preserved. >=20 > [Joe] Two options, 1/ if the group decides to support the flow > termination method proposed in 3sm draft and assuming we agree on PCN > encoding where CE=3Dflow terminate, than a CE marked packet can be > interoperate as this flow needs to be terminate. The ingress lets the > packet into as is and the egress open seeing flow termination (CE) > market packet does the flow termination procedure. > 2./ The PCN-ingress node open detecting CE market packet, drops the CE > marked packet. > Now I have a question for you, is the flow in question PCN-capable? If > yes than this is a case where a PCN-capable flow hits an ECN-capable > router and should be rate reduce. [joe end] >=20 > One possibility is that this is a scenario that we don't need to worry > about. If it is one we need to think about, then there are two > possibilities for how PCN WG could think about it: > [Joe] I think we need to worry about. [joe end]. >=20 > (1) when such traffic reaches the PCN-domain, then tunnel it across the > PCN-domain. this means that upon decapsulation at the egress any ECN-CE > marking (that was there when the pkt reached the ingress) is preserved. >=20 > [Joe] Why do you want to preserve ECN-CE marking of packet that is > PCN-capable? If the ECN-CE marked packet does not belong to PCN-capable > flow, that use a different DSCP and possible a service class within the > PCN-domain that also supports ECN traffic. > My assumption is that the diffserv domain has at least two service > classes, a PCN-cable service class and others service class(es) for > non-PCN traffic. > Tunnel would only be needed if there is only one service class and it > was PCN-cable. I do not believe we are proposing this.[joe end] >=20 > (2) devise an encoding scheme for PCN that preserves the ECN-CE marking. > these are the two possibilities i was trying to lay out in my original > email, ie > (1) deal with the issue in the architecture doc by saying a tunnelling > solution could be done to solve the problem > (2) in the encoding-comparison doc, examine what the impact of this > would be on PCN-encoding (to inform the eventual choice of encoding) > [Joe] The encoding-comparison draft needs to discuss possible marking > interaction between ECN and PCN and propose combination(s) that best > meet guidelines in RFC 4774. > I think in the architecture draft we need to talk about the issue, > should look at RFC 4774 and see which case apply to PCN-domain. >=20 > Maybe, I'm missing something, but I do not think that we need to tunnel > ECN-marked traffic across PCN-domain. [joe end] >=20 > phil >=20 >=20 > ________________________________ >=20 > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: Thu 26/07/2007 22:26 > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions >=20 >=20 >=20 > Phil and all see below. >=20 > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: July 26, 2007 4:35 PM > To: pcn@ietf.org > Subject: [PCN] PCN & ECN-(congestion experienced) interactions >=20 > >=20 > >the second issue is about what happens if traffic arrives at the > PCN-domain >(for the PCN traffic class) that is already marked with > ECN's CE codepoint >(congestion experienced). ie the issue is how to > handle traffic which for >some reason is using ECN (end-to-end) and also > using PCN admission control >(across the PCN-domain). this could be an > issue for the pcn-architecture >draft, and also for the > chan-pcn-encoding one. certainly it's an issue >that's got to be dealt > with by at least one of these drafts. >=20 > [Joe] If a packet belonging to a PCN-capable flow arrives at the > PCN-domain, the ECN field should not be touched. What ever the encoding > of the bits is it is forwarded that way. OK, I'm assuming that PCN can > be end-to-end some day. > However, if packet belonging to a flow that is not PCN-traffic arrives > at the PCN-domain it gets forwarded using a different forwarding class > (DSCP) than what is used for PCN traffic. The PCN-domain uses Diffserv > to provide the differentiation. Only PCN traffic get's the PCN > treatment. >=20 >=20 > >bob says: >=20 > >>>Although this is perhaps too detailed for the architecture, I suggest > >that any need for ECN marking on the same path but outside the PCN > [Joe] >domain(s) should be handled by tunnelling across the PCN domain, > with a >non-PCN DSCP in the inner header (that turns on the RFC3168 > meaning of its >ECN field) and a PCN DSCP in the outer.>> > [Joe] I do not understand. I though that we state that we would use > Diffserv. Why tunnel? >=20 > >one possibility is to deal with this now, with the wording along the > lines >that bob suggests above added to the architecture draft. > basically say that >a solution on these lines would solve the problem > (there may be others but >we won't think about them). > [Joe] We do not need to tunnel. >=20 > >another possibility is that the encoding comparison draft includes a > look >at the implications of a pkt being able to be PCN-marked whilst > preserving >its ECN-CE - ie the effect in terms of how the PCN-encoding > is done. we >could end up deciding that it was worthwhile, orthat it > wasn't worthwhile. >In the latter case we would go back to bob's > solution above. > [Joe] Let's do it in the architecture draft. The marking draft should be > only a survey of viable marking options. >=20 > >do people feel able to make a decision now to go for the first > possibility >(as bob suggests - I'd be OK with this too) or do we want > discussion within >the encoding-comparisons draft? > [Joe] We do not need to mix ECN marking behavior and PCN marking > behavior. My assumption is that we where going to use Diffserv and DS > codepoints to separate traffic that is PCN-capable from traffic that is > not PCN-capable. >=20 > >thanks, phil >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 03 21:27:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH8QU-0008Jx-Cz; Fri, 03 Aug 2007 21:27:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IH8QT-0008Iu-4j for pcn-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 21:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH8QS-0008Gl-PI for pcn@ietf.org; Fri, 03 Aug 2007 21:27:28 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH8QS-0006XK-DX for pcn@ietf.org; Fri, 03 Aug 2007 21:27:28 -0400 Received: by an-out-0708.google.com with SMTP id c17so188676anc for ; Fri, 03 Aug 2007 18:27:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X68dpTM04kAKOdsTIVpedyYGYWcx57a2pFJX0YMkSGaBUiRXoYe4ylwUi75tqHH7nIlJt9dR1MHatWKG4nZU82PznOaKQPiZwQBffbaFNDsBWO9c0druHU6lzBC68r3ANJLXT+153oPqDgBnv561DfmpBpmhgcbQM014PkKi7ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oxzdEa659KEfjwlgRti9gnapM6fZmyFu8e1lpMmyRmJU9ur+9D54v1TJvc4Nm86DW3dQt0IiVJyVl9w7MQw+AuBGTutEMcu2jhKLNUrkPg5MKMvJepFYJwWjIuim4nQX8Y9Xu3WFwukRvfvGzefi5Jore5I8N8Iqx2zKKplvvjM= Received: by 10.100.190.8 with SMTP id n8mr2047844anf.1186190847868; Fri, 03 Aug 2007 18:27:27 -0700 (PDT) Received: by 10.100.144.10 with HTTP; Fri, 3 Aug 2007 18:27:27 -0700 (PDT) Message-ID: Date: Fri, 3 Aug 2007 18:27:27 -0700 From: "Lachlan Andrew" To: "philip.eardley@bt.com" Subject: Re: [PCN] PCN & ECN-(congestion experienced) interactions In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37F@E03MVZ1-UKDY.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9671A92C3C8B5744BC97F855F7CB64651175461B@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37F@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: l.andrew@ieee.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org That sounds good, as long as the dropping behaviour isn't set in stone and can be revised if/when someone does devise something cleverer. Cheers, Lachlan On 03/08/07, philip.eardley@bt.com wrote: > > If a packet that is part of a PCN-flow arrives at a PCN-ingress-node > with its CE (Congestion experienced) codepoint set, then we assume that > the PCN-ingress-node drops the packet. > > > There are lots of other possible behaviours that could be explored, but > this assumption has the merit I think of being simple and sound > (ECN-friendly) - and means we don't expend effort devising something > cleverer (at least until we've finished doing the initial pcn charter). > > Everyone happy - or at least not too unhappy? -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 06 00:55:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHubb-0007zx-CO; Mon, 06 Aug 2007 00:54:11 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IHubZ-0007zs-J0 for pcn-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 00:54:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHubZ-0007zk-87 for pcn@ietf.org; Mon, 06 Aug 2007 00:54:09 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHubX-0003Ra-2Q for pcn@ietf.org; Mon, 06 Aug 2007 00:54:09 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMC00FAK5L4LR@szxga02-in.huawei.com> for pcn@ietf.org; Mon, 06 Aug 2007 12:53:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMC003II5L4XK@szxga02-in.huawei.com> for pcn@ietf.org; Mon, 06 Aug 2007 12:53:28 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMC0031F5L3MC@szxml04-in.huawei.com> for pcn@ietf.org; Mon, 06 Aug 2007 12:53:27 +0800 (CST) Date: Mon, 06 Aug 2007 12:53:27 +0800 From: Tina TSOU Subject: Re: [PCN] Re: How to discuss WG scoping decisions in an RFC? To: steven.blake@ericsson.com, menth@informatik.uni-wuerzburg.de, philip.eardley@bt.com Message-id: <017301c7d7e5$ba7bd9f0$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37E@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org ----- Original Message ----- From: To: ; Cc: Sent: Saturday, August 04, 2007 2:09 AM Subject: RE: [PCN] Re: How to discuss WG scoping decisions in an RFC? Michael & Steve said: > > Regarding emergency use: the charter says: > > > > (D) flows may have different precedence, but the applicability > > of the PCN mechanisms for emergency use (911, GETS, WPS, > > MLPP, etc.) is out of scope > > > > This could be interpreted in more than one way, but I interpret this as > > saying that PCN-specific mechanisms will not take flow precedence into > > account. Which is a different than saying that PCN cannot be used with > > flow setup protocols/mechanisms that take flow precedence into account. > > > > As soon as we have multiple PCN classes it might be useful to think > about flow precedence especially with regard to admission and > termination priority. Equal treatment of flows means that a highly > critical telemedicine application has the same probability to be > terminated as a "relatively" uncritcical VoIP call in case of a > disaster. I read the passage in the way that it's not our job to define > mechanisms for emergency use, but it is not prohibited to extend PCN > towards multiple classes with different requirements although this is > not the first thing to do. The conclusion I take from this is that the Architecture doc Assumptions section should just repeat what the Charter says. Any objections? [Tina: No objection. But there are some comments. The Assumptions in the current Architecture Doc are concrete, may help readers to understand which conditions our Arch is more useful.] Thanks, phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 06 07:10:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II0TK-00029H-LU; Mon, 06 Aug 2007 07:10:02 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1II0TJ-000298-7U for pcn-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 07:10:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II0TF-00028b-AI for pcn@ietf.org; Mon, 06 Aug 2007 07:09:57 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II0TD-0003Tr-HJ for pcn@ietf.org; Mon, 06 Aug 2007 07:09:57 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:09:07 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Date: Mon, 6 Aug 2007 12:09:04 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC383@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Thread-Index: AcfOTJNiDbXXskhTRKOfZp0Z2OHPEQJzReIA From: To: X-OriginalArrivalTime: 06 Aug 2007 11:09:07.0930 (UTC) FILETIME=[355BB3A0:01C7D81A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org One issue I wanted to flag from the comments in your PDF. In S4, in the part that begins "The following are some high-level points about how PCN works:" You added the bullet: "o It is assumed that PCN marking is being applied to traffic scheduled with the expedited forwarding [RFC3246] per-hop behaviour." Do people agree with adding this bullet? Thanks Phil/ > -----Original Message----- > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R > Sent: 25 July 2007 00:44 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 > Phil and all the authors of this PCN architecture draft, >=20 > Like Lars, I'd like to congratulate you all on such a mature first draft, > and on managing to encompass many different views we have seen from > various > people without making the thing an uncontrollable monster full of options > and choices. >=20 > I just read it all through and my review comments are given below. >=20 > Also see > t-eardley-pcn-architecture-00_rvw_bb.pdf> > for suggested minor text changes. >=20 > I haven't supplied text for more major changes inline below until the > authors agree with the need for change. But then I can supply text if > required. >=20 > At 16:59 28/06/2007, philip.eardley@bt.com wrote: > >Hi all, > > > >Just a reminder that all comments on this draft would be great. It aims > >to describe the PCN architecture, in light of the PCN WG's Charter & its > >Milestone of an Info doc on 'Flow Admission and Termination Architecture > >within a Diffserv Domain' (due Nov 07). >=20 > General comments: >=20 > * WG process management > A lot of WG process management text, esp in S.3, but also the list of > possible flow termination mechanisms in S.4. All instances hilited in > magenta in the review at the above URL. > See separate mail about this to the PCN WG chairs (cc PCN list) > Subject: How to discuss WG scoping decisions in an RFC? >=20 > * Choices vs decisions > I believe an architecture doc should say where one decision is required or > where multiple options are reasonable. Currently, the arch is good at > laying out the design space, but I'd like us to try to say which choices > have to be made by the IETF, which should be left to vendors and which > left > to operators. >=20 > >S1 Introduction. > >This is quite short. If desired, it could be boosted with a general > >explanation of where PCN fits into the picture of QoS and how it's > >evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01) >=20 > * Clarify that a packet might encounter more than one PCN domain along its > path, each being a separate admission control hop. >=20 > * Clarify that a "Diffserv domain" may be multiple concatenated autonomous > systems, but in this draft they are assumed to trust each other and have > identical configuration. >=20 > >S2 Terminology > >In the "Editor's note" are 3 alternative terms that some of the authors > >preferred. >=20 > * ECN _and_ PCN marking? >=20 > " o Configured-termination-rate: [...] > Normally it is configured to be less than > the maximum rate at which PCN-traffic can be forwarded on the > link, so that termination-marking occurs before any significant > queuing, ECN-marking or loss of PCN-packets. > " >=20 > The above text implies (to me) that a PCN-interior router might do PCN > marking _and_ also ECN marking just before drop. That also imposes a > requirement on the encoding to be able to carry either in the same field. > I don't think the authors meant either of these implications. So > somewhere, > the relation between PCN & ECN marking should be stated. >=20 > Although this is perhaps too detailed for the architecture, I suggest that > any need for ECN marking on the same path but outside the PCN domain(s) > should be handled by tunnelling across the PCN domain, with a non-PCN DSCP > in the inner header (that turns on the RFC3168 meaning of its ECN field) > and a PCN DSCP in the outer. >=20 > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. >=20 > The unintended implication that all packets are either marked or not > marked > should also be carefully avoided. The draft needs to say explicitly that > "Admission (or Termination) marking will be an encoding of some > combination > of codepoints in the IP header to signal a varying fractional number from > a > path of PCN-interior-nodes to a PCN-egress-node" >=20 > * inelastic > Do you think we should define "inelastic" or is this a well-known IETF > term? We could refer to [Shenker95], which I think was the first to define > the term. Or is there an RFC that defines this (hopefully with ref to > Shenker)? >=20 > Scott Shenker, "Fundamental Design Issues for the Future Internet", In: > IEEE Journal on Selected Areas in Communications 13 (7) pp. 1176--1188 > (1995). >=20 >=20 > >S3 Assumptions and constraints on scope > >These are the 4 things mentioned in the Charter, plus some explanation > >of them. Are they clear? Also we mention some of the ways that a future > >revised Charter might look at overcoming some of the > >constraints/assumptions; is this sub-section at the right depth? >=20 > * Are all the scoping assumptions equal relaxable? >=20 > Just a thought: might it be worth giving an indication of which > assumptions > are likely to be hard or impossible to relax and which not (e.g. I think > the aggregation assumption is implicit to all MBAC (measurement-based Adm > Ctrl). Also inelasticity is fairly fundamental - you don't need admission > control if flows aren't inelastic. >=20 > This would affect the last para, which implies all the assumptions might > be > relaxed one day. >=20 > >S4 High-level functional architecture > >We have tried to write this section (and the following ones) so that it > >fits all the various proposals there've been for PCN mechanisms. Does > >this make the section too wishy-washy or too hard to understand? Should > >it include some comparison of the different mechanisms proposed > >(PCN-interior-node marking algorithms & PCN-boundary-node reactions)? >=20 > * Functional or topological? > Is it intentional that the high level functions are classified by which > type of node does them in 3 cases and what function is to be done in the > others? Would it be possible to define functions in the abstract first, > then say which functions have to be implemented on certain types of nodes? > Or does this just make it unnecessarily incomprehensible? >=20 > Gaps: > 1/ Discuss which PCN node needs to know the IP address of which other PCN > node in different configurations. And state requirements this implies on > the signalling protocol, or on configuration. > Minimally, only the egress needs to know the ingress address. In > centralised admission control scenarios, either the egress or the ingress > or both might need to be configured with a central address. >=20 > 2/ Related to knowing addresses of other nodes: When a PCN node receives a > message claiming to be from another PCN node, to validate the msg is > indeed > from the node it claims to be, are there any different issues that PCN > raises relative to typical reservation signalling systems? > draft-lefaucheur-rsvp-ecn-01 (expired) contains a good deal of text on > this > issue that should be generalised into this arch doc. >=20 > >S5 Detailed Functional architecture > >Is this a reasonable description of the extra functionality that PCN > >requires on various nodes in the PCN-domain? Is it the right way to > >split up the description? For clarity / help reader's understanding, > >should there be some specific examples of how functionality might be > >distributed (eg "if you followed the deployment model in > >draft-briscoe-tsvwg-cl-architecture-04, then this measurement is made at > >the PCN-egress-node, communicated to the PCN-ingress-nodes which makes > >the admission decision; etc.") >=20 > S.5.5 Probing functions >=20 > If we are going to consider a case where the ingress has prior knowledge > of > which egress is associated with which destination address (e.g. with a > separate signalling routing table as discussed in NSIS, or if the > signalling protocol goes receiver-sender-receiver), then the ingress could > know that it has no reservations with that egress as soon as a reservation > request arrives, so it can unilaterally start probling. >=20 > S.5.6 Flow Termination Functions >=20 > The text seems to assume the egress makes the decision on which flows to > lose and tells the ingress. In cl-architecture (for instance) the egress > meters, feeds back the measurement to the ingress, which meters the load > it > is forwarding and then the ingress calculates how much traffic to > terminate, and either chooses the flows itself, or asks a central node to > choose. >=20 > I think there has to be metering at both boundaries otherwise we can't > work > out how much traffic has been dropped (as well as termination marked). The > decision might be at either (but in cl-architecture we had good reasons > for > choosing the ingress because it has the most recent knowledge about load > (given flows might be being abandoned by users very quickly and/or added > very quickly during a disaster). >=20 > Other more incremental mechanisms have now been defined that don't > calculate how much load to shed in one pass, but keep trying. Have we > abandonned the earlier approach? >=20 > Whatever, I think a feedback function is missing between the boundary > nodes. >=20 > >S6 Design goals and challenges > >This briefly describes some open issues, taken from > >briscoe-tsvwg-cl-architecture. Are there other ones that should be > >mentioned? Is the problem description at the right level of depth? > >Should we discuss various possible solutions to these problems? >=20 > I get the feeling we need a doc specifically on ECMP solutions? >=20 > >S7 Deployment scenarios > >Briefly describes some deployment scenarios for pcn? is this at the > >right level of depth? >=20 > Just a thought - I felt this section would have been better earlier. >=20 > >S8 Operations and Management > >This section was written in response to the Charter saying that the > >architecture document should include security, manageability and > >operational considerations. The draft addresses this by providing some > >thoughts under the FCAPS headings: OAM of Faults, Configuration, > >Accounting, Performance and Security? Is this the right way of > >structuring it - does it cover the right set of topics? Is the text at > >the right level? - eg should it also have a detailed set of parameters > >that would be available for configuration? >=20 > * Don't think this is Fault OAM? > Echoing what someone else (I forget who) said on the list, Fault OAM isn't > really about how the control system recovers from failures (that's > control), it's how to tell the management system/manual operator that you > have recovered from a failure (or not). >=20 > Also, we should cover faults other than node or link failures. E.g. a > wrongly configured address in a node, or a wrong address given in a > singalling protocol, or a wrongly configured parameter in a queueing algo. > Etc. >=20 > * Config OAM: Add: > - level of AM that leads to denying new admissions. > - config paramteres that control distribution of functions? >=20 > * Don't think this is Performance OAM? > I think Perf OAM is about monitoring performance at run-time, not > characterising performance at design time. >=20 > * Don't think this is Security OAM? > Again, as someone said, security OAM is finding out about security > breaches > or near-misses at run-time, not identifying security flaws in the design, > which is security the considerations section. >=20 > * Security Considerations Gaps: > - PCN marking selectively applied to certain flows, rather than randomly > by > interior node. > - The statement about DoS attacks is a requirement with no pointers to the > detailed DOS issues, or any discussion of best practice design. I could > supply text here (among many other things to do!) > - ref to hop-by-hop signalling authentication [RFC2747 for RSVP] and the > new recently posted draft to tsvwg on group keying for RSVP authentication > . I haven't read > it > yet, but on a scan it's as relevant as RFC2747. >=20 >=20 > Phew... that's all for now. >=20 >=20 > Bob >=20 >=20 > >An overall question is whether the draft should have more comparison of > >the options (pros/cons) for various aspects. > > > >I aim to edit another version of the draft before the ietf (but maybe > >not before the deadline as I'm on hols next week). > > > >Thanks! > >Phil/ >=20 > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 06 07:31:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II0nl-0002LT-6T; Mon, 06 Aug 2007 07:31:09 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1II0nj-0002LL-TN for pcn-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 07:31:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II0nj-0002LD-Jv for pcn@ietf.org; Mon, 06 Aug 2007 07:31:07 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II0ni-0003ue-5B for pcn@ietf.org; Mon, 06 Aug 2007 07:31:07 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 12:31:05 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions Date: Mon, 6 Aug 2007 12:31:04 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC384@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & ECN-(congestion experienced) interactions Thread-Index: AcfWNp8K0IlJwVpxSwmHDvEAHNzkEAB5dfQA From: To: X-OriginalArrivalTime: 06 Aug 2007 11:31:05.0166 (UTC) FILETIME=[467DF6E0:01C7D81D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Perhaps we should say this explicitly. So the text would read:=20 If a packet that is part of a PCN-flow arrives at a PCN-ingress-node with its CE (Congestion experienced) codepoint set, then we assume that the PCN-ingress-node drops the packet. After its initial Charter is complete, the WG may decide to work on a mechanism (such as through a signalling extension) that enables ECN-marking to be carried transparently across the PCN-domain. Ok? phil > -----Original Message----- > From: Lachlan Andrew [mailto:lachlan.andrew@gmail.com] > Sent: 04 August 2007 02:27 > To: Eardley,PL,Philip,CXR9 R > Cc: babiarz@nortel.com; pcn@ietf.org > Subject: Re: [PCN] PCN & ECN-(congestion experienced) interactions >=20 > That sounds good, as long as the dropping behaviour isn't set in stone > and can be revised if/when someone does devise something cleverer. >=20 > Cheers, > Lachlan >=20 > On 03/08/07, philip.eardley@bt.com wrote: > > > > If a packet that is part of a PCN-flow arrives at a PCN-ingress-node > > with its CE (Congestion experienced) codepoint set, then we assume that > > the PCN-ingress-node drops the packet. > > > > > > There are lots of other possible behaviours that could be explored, but > > this assumption has the merit I think of being simple and sound > > (ECN-friendly) - and means we don't expend effort devising something > > cleverer (at least until we've finished doing the initial pcn charter). > > > > Everyone happy - or at least not too unhappy? >=20 >=20 > -- > Lachlan Andrew Dept of Computer Science, Caltech > 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA > Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 06 07:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II19W-0004QB-SE; Mon, 06 Aug 2007 07:53:38 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1II19V-0004Q1-B3 for pcn-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 07:53:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II19U-0004Pt-V8 for pcn@ietf.org; Mon, 06 Aug 2007 07:53:37 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II19S-0006JP-2F for pcn@ietf.org; Mon, 06 Aug 2007 07:53:36 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMC000TOP039L@szxga03-in.huawei.com> for pcn@ietf.org; Mon, 06 Aug 2007 19:52:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMC00INIP00XO@szxga03-in.huawei.com> for pcn@ietf.org; Mon, 06 Aug 2007 19:52:51 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMC00AK1P00JQ@szxml03-in.huawei.com> for pcn@ietf.org; Mon, 06 Aug 2007 19:52:48 +0800 (CST) Date: Mon, 06 Aug 2007 19:52:48 +0800 From: Tina TSOU Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt To: rbriscoe@jungle.bt.co.uk, philip.eardley@bt.com Message-id: <008e01c7d820$4f4d7d60$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC383@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, I agree with adding it. B. R. Tina ----- Original Message ----- From: To: Cc: Sent: Monday, August 06, 2007 7:09 PM Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt One issue I wanted to flag from the comments in your PDF. In S4, in the part that begins "The following are some high-level points about how PCN works:" You added the bullet: "o It is assumed that PCN marking is being applied to traffic scheduled with the expedited forwarding [RFC3246] per-hop behaviour." Do people agree with adding this bullet? Thanks Phil/ > -----Original Message----- > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R > Sent: 25 July 2007 00:44 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > Phil and all the authors of this PCN architecture draft, > > Like Lars, I'd like to congratulate you all on such a mature first draft, > and on managing to encompass many different views we have seen from > various > people without making the thing an uncontrollable monster full of options > and choices. > > I just read it all through and my review comments are given below. > > Also see > t-eardley-pcn-architecture-00_rvw_bb.pdf> > for suggested minor text changes. > > I haven't supplied text for more major changes inline below until the > authors agree with the need for change. But then I can supply text if > required. > > At 16:59 28/06/2007, philip.eardley@bt.com wrote: > >Hi all, > > > >Just a reminder that all comments on this draft would be great. It aims > >to describe the PCN architecture, in light of the PCN WG's Charter & its > >Milestone of an Info doc on 'Flow Admission and Termination Architecture > >within a Diffserv Domain' (due Nov 07). > > General comments: > > * WG process management > A lot of WG process management text, esp in S.3, but also the list of > possible flow termination mechanisms in S.4. All instances hilited in > magenta in the review at the above URL. > See separate mail about this to the PCN WG chairs (cc PCN list) > Subject: How to discuss WG scoping decisions in an RFC? > > * Choices vs decisions > I believe an architecture doc should say where one decision is required or > where multiple options are reasonable. Currently, the arch is good at > laying out the design space, but I'd like us to try to say which choices > have to be made by the IETF, which should be left to vendors and which > left > to operators. > > >S1 Introduction. > >This is quite short. If desired, it could be boosted with a general > >explanation of where PCN fits into the picture of QoS and how it's > >evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01) > > * Clarify that a packet might encounter more than one PCN domain along its > path, each being a separate admission control hop. > > * Clarify that a "Diffserv domain" may be multiple concatenated autonomous > systems, but in this draft they are assumed to trust each other and have > identical configuration. > > >S2 Terminology > >In the "Editor's note" are 3 alternative terms that some of the authors > >preferred. > > * ECN _and_ PCN marking? > > " o Configured-termination-rate: [...] > Normally it is configured to be less than > the maximum rate at which PCN-traffic can be forwarded on the > link, so that termination-marking occurs before any significant > queuing, ECN-marking or loss of PCN-packets. > " > > The above text implies (to me) that a PCN-interior router might do PCN > marking _and_ also ECN marking just before drop. That also imposes a > requirement on the encoding to be able to carry either in the same field. > I don't think the authors meant either of these implications. So > somewhere, > the relation between PCN & ECN marking should be stated. > > Although this is perhaps too detailed for the architecture, I suggest that > any need for ECN marking on the same path but outside the PCN domain(s) > should be handled by tunnelling across the PCN domain, with a non-PCN DSCP > in the inner header (that turns on the RFC3168 meaning of its ECN field) > and a PCN DSCP in the outer. > > * Marking is when "current" rate is "above" a reference rate? > > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. > > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " > > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. > > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. > > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. > > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. > > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. > > The unintended implication that all packets are either marked or not > marked > should also be carefully avoided. The draft needs to say explicitly that > "Admission (or Termination) marking will be an encoding of some > combination > of codepoints in the IP header to signal a varying fractional number from > a > path of PCN-interior-nodes to a PCN-egress-node" > > * inelastic > Do you think we should define "inelastic" or is this a well-known IETF > term? We could refer to [Shenker95], which I think was the first to define > the term. Or is there an RFC that defines this (hopefully with ref to > Shenker)? > > Scott Shenker, "Fundamental Design Issues for the Future Internet", In: > IEEE Journal on Selected Areas in Communications 13 (7) pp. 1176--1188 > (1995). > > > >S3 Assumptions and constraints on scope > >These are the 4 things mentioned in the Charter, plus some explanation > >of them. Are they clear? Also we mention some of the ways that a future > >revised Charter might look at overcoming some of the > >constraints/assumptions; is this sub-section at the right depth? > > * Are all the scoping assumptions equal relaxable? > > Just a thought: might it be worth giving an indication of which > assumptions > are likely to be hard or impossible to relax and which not (e.g. I think > the aggregation assumption is implicit to all MBAC (measurement-based Adm > Ctrl). Also inelasticity is fairly fundamental - you don't need admission > control if flows aren't inelastic. > > This would affect the last para, which implies all the assumptions might > be > relaxed one day. > > >S4 High-level functional architecture > >We have tried to write this section (and the following ones) so that it > >fits all the various proposals there've been for PCN mechanisms. Does > >this make the section too wishy-washy or too hard to understand? Should > >it include some comparison of the different mechanisms proposed > >(PCN-interior-node marking algorithms & PCN-boundary-node reactions)? > > * Functional or topological? > Is it intentional that the high level functions are classified by which > type of node does them in 3 cases and what function is to be done in the > others? Would it be possible to define functions in the abstract first, > then say which functions have to be implemented on certain types of nodes? > Or does this just make it unnecessarily incomprehensible? > > Gaps: > 1/ Discuss which PCN node needs to know the IP address of which other PCN > node in different configurations. And state requirements this implies on > the signalling protocol, or on configuration. > Minimally, only the egress needs to know the ingress address. In > centralised admission control scenarios, either the egress or the ingress > or both might need to be configured with a central address. > > 2/ Related to knowing addresses of other nodes: When a PCN node receives a > message claiming to be from another PCN node, to validate the msg is > indeed > from the node it claims to be, are there any different issues that PCN > raises relative to typical reservation signalling systems? > draft-lefaucheur-rsvp-ecn-01 (expired) contains a good deal of text on > this > issue that should be generalised into this arch doc. > > >S5 Detailed Functional architecture > >Is this a reasonable description of the extra functionality that PCN > >requires on various nodes in the PCN-domain? Is it the right way to > >split up the description? For clarity / help reader's understanding, > >should there be some specific examples of how functionality might be > >distributed (eg "if you followed the deployment model in > >draft-briscoe-tsvwg-cl-architecture-04, then this measurement is made at > >the PCN-egress-node, communicated to the PCN-ingress-nodes which makes > >the admission decision; etc.") > > S.5.5 Probing functions > > If we are going to consider a case where the ingress has prior knowledge > of > which egress is associated with which destination address (e.g. with a > separate signalling routing table as discussed in NSIS, or if the > signalling protocol goes receiver-sender-receiver), then the ingress could > know that it has no reservations with that egress as soon as a reservation > request arrives, so it can unilaterally start probling. > > S.5.6 Flow Termination Functions > > The text seems to assume the egress makes the decision on which flows to > lose and tells the ingress. In cl-architecture (for instance) the egress > meters, feeds back the measurement to the ingress, which meters the load > it > is forwarding and then the ingress calculates how much traffic to > terminate, and either chooses the flows itself, or asks a central node to > choose. > > I think there has to be metering at both boundaries otherwise we can't > work > out how much traffic has been dropped (as well as termination marked). The > decision might be at either (but in cl-architecture we had good reasons > for > choosing the ingress because it has the most recent knowledge about load > (given flows might be being abandoned by users very quickly and/or added > very quickly during a disaster). > > Other more incremental mechanisms have now been defined that don't > calculate how much load to shed in one pass, but keep trying. Have we > abandonned the earlier approach? > > Whatever, I think a feedback function is missing between the boundary > nodes. > > >S6 Design goals and challenges > >This briefly describes some open issues, taken from > >briscoe-tsvwg-cl-architecture. Are there other ones that should be > >mentioned? Is the problem description at the right level of depth? > >Should we discuss various possible solutions to these problems? > > I get the feeling we need a doc specifically on ECMP solutions? > > >S7 Deployment scenarios > >Briefly describes some deployment scenarios for pcn? is this at the > >right level of depth? > > Just a thought - I felt this section would have been better earlier. > > >S8 Operations and Management > >This section was written in response to the Charter saying that the > >architecture document should include security, manageability and > >operational considerations. The draft addresses this by providing some > >thoughts under the FCAPS headings: OAM of Faults, Configuration, > >Accounting, Performance and Security? Is this the right way of > >structuring it - does it cover the right set of topics? Is the text at > >the right level? - eg should it also have a detailed set of parameters > >that would be available for configuration? > > * Don't think this is Fault OAM? > Echoing what someone else (I forget who) said on the list, Fault OAM isn't > really about how the control system recovers from failures (that's > control), it's how to tell the management system/manual operator that you > have recovered from a failure (or not). > > Also, we should cover faults other than node or link failures. E.g. a > wrongly configured address in a node, or a wrong address given in a > singalling protocol, or a wrongly configured parameter in a queueing algo. > Etc. > > * Config OAM: Add: > - level of AM that leads to denying new admissions. > - config paramteres that control distribution of functions? > > * Don't think this is Performance OAM? > I think Perf OAM is about monitoring performance at run-time, not > characterising performance at design time. > > * Don't think this is Security OAM? > Again, as someone said, security OAM is finding out about security > breaches > or near-misses at run-time, not identifying security flaws in the design, > which is security the considerations section. > > * Security Considerations Gaps: > - PCN marking selectively applied to certain flows, rather than randomly > by > interior node. > - The statement about DoS attacks is a requirement with no pointers to the > detailed DOS issues, or any discussion of best practice design. I could > supply text here (among many other things to do!) > - ref to hop-by-hop signalling authentication [RFC2747 for RSVP] and the > new recently posted draft to tsvwg on group keying for RSVP authentication > . I haven't read > it > yet, but on a scan it's as relevant as RFC2747. > > > Phew... that's all for now. > > > Bob > > > >An overall question is whether the draft should have more comparison of > >the options (pros/cons) for various aspects. > > > >I aim to edit another version of the draft before the ietf (but maybe > >not before the deadline as I'm on hols next week). > > > >Thanks! > >Phil/ > > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 06 13:43:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II6c6-0001Jo-NV; Mon, 06 Aug 2007 13:43:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1II6c5-0001Jf-9C for pcn-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 13:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II6c4-0001JT-Rc for pcn@ietf.org; Mon, 06 Aug 2007 13:43:28 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II6c3-0003iy-EO for pcn@ietf.org; Mon, 06 Aug 2007 13:43:28 -0400 Received: by an-out-0708.google.com with SMTP id c17so292553anc for ; Mon, 06 Aug 2007 10:43:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gHZtmjKt3fi4f8CwWpJ9nv2gTeF9FkaGtU12XdCaghCZNbfkWidsMtO9DHwpR/RF1jodxn6JtObYMTnwyMdEFltv4Ws4glZomQ6RMWZWwyZi0kDI944zfziorQ7T1lbN/iY6RpswWrKvhZfGuYrc2sZqXz34/sgwSCTbBun7cEA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dy6i7OwRT6OAg6md6aI5sMnSAjxuhYNRPN+whfL9vdal11pxdQY2iOKymf+IVvBQbORsVyZE5pqI/whaFDh7fbWS2cTFc+3R6aXl1F/mKPszc9+VWQeoqqt9/pXMSJaqtiC/2VOgMSv9AXpAltuueHElT2uawjJoTplWI2RXba4= Received: by 10.100.141.13 with SMTP id o13mr3284833and.1186422205811; Mon, 06 Aug 2007 10:43:25 -0700 (PDT) Received: by 10.100.144.10 with HTTP; Mon, 6 Aug 2007 10:43:25 -0700 (PDT) Message-ID: Date: Mon, 6 Aug 2007 10:43:25 -0700 From: "Lachlan Andrew" To: "philip.eardley@bt.com" Subject: Re: [PCN] PCN & ECN-(congestion experienced) interactions In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC384@E03MVZ1-UKDY.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC384@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: l.andrew@ieee.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Sounds excellent. Lachlan On 06/08/07, philip.eardley@bt.com wrote: > Perhaps we should say this explicitly. So the text would read: > > If a packet that is part of a PCN-flow arrives at a PCN-ingress-node > with its CE (Congestion experienced) codepoint set, then we assume that > the PCN-ingress-node drops the packet. > After its initial Charter is complete, the WG may decide to work on a > mechanism (such as through a signalling extension) that enables > ECN-marking to be carried transparently across the PCN-domain. > > Ok? > > phil -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 06 16:38:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9L2-0000RV-KG; Mon, 06 Aug 2007 16:38:04 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1II9L1-0000RK-O6 for pcn-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9L1-0000RC-EN for pcn@ietf.org; Mon, 06 Aug 2007 16:38:03 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9L0-0001g0-35 for pcn@ietf.org; Mon, 06 Aug 2007 16:38:03 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l76KfbFX008523; Mon, 6 Aug 2007 15:41:43 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 15:37:15 -0500 Received: from [147.117.169.108] ([147.117.169.108]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 15:37:15 -0500 Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions From: Steven Blake To: philip.eardley@bt.com In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37F@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37F@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Mon, 06 Aug 2007 16:37:14 -0400 Message-Id: <1186432634.3449.24.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2007 20:37:15.0149 (UTC) FILETIME=[92EC8BD0:01C7D869] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Fri, 2007-08-03 at 19:32 +0100, philip.eardley@bt.com wrote: > Joe, you've persuaded me that your approach is better. I suggest we add > text along the lines of your second Option (the first assumes a > particular mechanism /encoding is chosen). Ie add (probably to end of > Section 4): > > If a packet that is part of a PCN-flow arrives at a PCN-ingress-node > with its CE (Congestion experienced) codepoint set, then we assume that > the PCN-ingress-node drops the packet. > > > There are lots of other possible behaviours that could be explored, but > this assumption has the merit I think of being simple and sound > (ECN-friendly) - and means we don't expend effort devising something > cleverer (at least until we've finished doing the initial pcn charter). > > Everyone happy - or at least not too unhappy? Philip, Please correct me if I am wrong, but this is only an issue if PCN were to choose to use the ECN bits for PCN marking, right? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 06 18:17:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAsI-0003KF-OK; Mon, 06 Aug 2007 18:16:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIAsH-0003KA-Ic for pcn-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 18:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAsG-0003K2-VS for pcn@ietf.org; Mon, 06 Aug 2007 18:16:28 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIAsF-0004SJ-DX for pcn@ietf.org; Mon, 06 Aug 2007 18:16:28 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 7F7A26DAC; Tue, 7 Aug 2007 00:16:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6EA49AF98; Tue, 7 Aug 2007 00:16:24 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 322476DAC; Tue, 7 Aug 2007 00:16:24 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l76MGNh02997; Tue, 7 Aug 2007 00:16:23 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 7C7156F591; Tue, 7 Aug 2007 00:10:20 +0200 (CEST) Message-ID: <46B79CF2.7070806@informatik.uni-wuerzburg.de> Date: Tue, 07 Aug 2007 00:13:06 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] PCN terminology References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37D@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC37D@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil and others, as far as I can remember, we were about to discuss on the list the use of 1) "(configured-)admission rate" vs. "admissible rate" for the PCN lower=20 threshold. 2) "admission marking" vs. "admission-stop marking" for the marking=20 associated with the PCN lower threshold. which are very similar and it shouldn't be a problem to find a consensus=20 for one of them. As PCN is used for admission control, and as all proposals I am aware=20 of, use the admissible rate threshold and the associated marking to=20 support admission control, I don't see the need for neutral names like=20 "lower PCN threshold". I don't find them good because they hide the=20 purpose the defined mechanism and make explanations more difficult. I=20 was unable to attend the meeting in Chicago, so I miss the reasons for=20 neutral instead of mnemonic names. What's the motivation behind this, in=20 particular for the lower PCN threshold? Regards, Michael philip.eardley@bt.com wrote: > > Hi, > > I=92m starting to do the mods in order to create=20 > draft-ietf-pcn-architecture-00, based on=20 > draft-eardley-pcn-architecture-00. > > One of the things is to adapt the PCN terminology. The consensus at=20 > the WG in Chicago was to move to names that are more =91neutral=92 and = to=20 > use names for marking that reflect how the marking is done (rather=20 > than what it is trying to achieve). I think that PCN-upper-rate &=20 > PCN-lower-rate, and threshold-marking and excess-rate-marking were=20 > mentioned. > > A copy and paste of the definitions isn=92t quite possible, are the=20 > following are OK? I also tried to take account of Bob=92s review commen= t=20 > (25 july on the list) that we shouldn=92t use =93rate=94 in the definit= ions=20 > loosely. > > =B7 PCN-lower-rate: a reference rate configured for each link in the=20 > PCN-domain, which is lower than the PCN-upper-rate. It is used by an=20 > algorithm that determines whether a packet should be PCN-marked with a=20 > first encoding > > =B7 PCN-upper-rate: a reference rate configured for each link in the=20 > PCN-domain, which is higher than the PCN-lower-rate. It is used by an=20 > algorithm that determines whether a packet should be PCN-marked with a=20 > second encoding. > > =B7 Threshold-marking: a PCN-marking algorithm such that all PCN-traffi= c=20 > is marked if the PCN-traffic exceeds a particular rate (either the=20 > PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the=20 > intent of the algorithm rather than its instantaneous behaviour, since=20 > the rate measured at a particular moment depends on the algorithm, its=20 > implementation and the traffic's variance as well as its rate > > =B7 Excess-rate-marking: a PCN-marking algorithm such that the amount o= f=20 > PCN-traffic that is PCN-marked is equal to the amount that exceeds a=20 > particular rate (either the PCN-lower-rate or PCN-upper-rate). NOTE:=20 > The definition reflects the intent of the algorithm rather than its=20 > instantaneous behaviour, since the rate measured at a particular=20 > moment depends on the algorithm, its implementation and the traffic's=20 > variance as well as its rate > > =B7 PCN-marking: either threshold-marking or excess-rate-marking > > {if necessary we can define: PCN-lower-rate-marking and=20 > PCN-upper-rate-marking} > > I=92ll remove the term ECN-marking, which is unnecessary. > > What do you reckon? > > Best wishes, > > phil > > -----------------------------------------------------------------------= - > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 07 03:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJQh-0000Qt-4P; Tue, 07 Aug 2007 03:24:35 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIJQf-0000LO-G8 for pcn-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 03:24:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJQf-0000LG-68 for pcn@ietf.org; Tue, 07 Aug 2007 03:24:33 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIJQe-00021o-LS for pcn@ietf.org; Tue, 07 Aug 2007 03:24:32 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 08:24:31 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions Date: Tue, 7 Aug 2007 08:24:30 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC38F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1186432634.3449.24.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & ECN-(congestion experienced) interactions Thread-Index: AcfYaa8y8PL6Nc34TCWHNjrIM75y2QAWkjlQ From: To: X-OriginalArrivalTime: 07 Aug 2007 07:24:31.0638 (UTC) FILETIME=[FF467B60:01C7D8C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Correct ( I think) > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: 06 August 2007 21:37 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions >=20 > On Fri, 2007-08-03 at 19:32 +0100, philip.eardley@bt.com wrote: >=20 > > Joe, you've persuaded me that your approach is better. I suggest we add > > text along the lines of your second Option (the first assumes a > > particular mechanism /encoding is chosen). Ie add (probably to end of > > Section 4): > > > > If a packet that is part of a PCN-flow arrives at a PCN-ingress-node > > with its CE (Congestion experienced) codepoint set, then we assume that > > the PCN-ingress-node drops the packet. > > > > > > There are lots of other possible behaviours that could be explored, but > > this assumption has the merit I think of being simple and sound > > (ECN-friendly) - and means we don't expend effort devising something > > cleverer (at least until we've finished doing the initial pcn charter). > > > > Everyone happy - or at least not too unhappy? >=20 > Philip, >=20 > Please correct me if I am wrong, but this is only an issue if PCN were > to choose to use the ECN bits for PCN marking, right? >=20 >=20 > Regards, >=20 > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 07 03:38:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJdh-0007oI-2Y; Tue, 07 Aug 2007 03:38:01 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIJdg-0007oC-55 for pcn-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 03:38:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJdf-0007o3-QZ for pcn@ietf.org; Tue, 07 Aug 2007 03:37:59 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIJde-0002Ru-Rp for pcn@ietf.org; Tue, 07 Aug 2007 03:37:59 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 08:37:58 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN terminology Date: Tue, 7 Aug 2007 08:37:57 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC390@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <46B79CF2.7070806@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN terminology Thread-Index: AcfYd22UVVYaKc7mTBiMWsqpSXvn9wATNsnA From: To: X-OriginalArrivalTime: 07 Aug 2007 07:37:58.0038 (UTC) FILETIME=[DFED5B60:01C7D8C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org - threshold-marking & excess-rate-marking: the general feeling was that the 'marking' names shouldn't reflect the (supposed) purpose to which receipt of the markings would be put, but rather should reflect the characteristic of the algorithm used to set the marking (how does it work?) - PCN-lower-rate and PCN-upper-rate: similarly, the general feeling was that the names for the configured rates shouldn't reflect the (supposed) purpose to which the rates are related. For example, with the single marking proposal, a single rate drives both flow admission ctrl and termination; in the future, markings associated with the PCN-upper-rate might drive flow adaptation as well as flow termination, and perhaps something similar could be imagined in the future for markings associated with the PCN-lower-rate (eg priority of the admitted traffic) well that was my take on the meeting's discussion/consensus! Best wishes, phil > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 06 August 2007 23:13 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN terminology >=20 > Hi Phil and others, >=20 > as far as I can remember, we were about to discuss on the list the use of > 1) "(configured-)admission rate" vs. "admissible rate" for the PCN lower > threshold. > 2) "admission marking" vs. "admission-stop marking" for the marking > associated with the PCN lower threshold. > which are very similar and it shouldn't be a problem to find a consensus > for one of them. >=20 > As PCN is used for admission control, and as all proposals I am aware > of, use the admissible rate threshold and the associated marking to > support admission control, I don't see the need for neutral names like > "lower PCN threshold". I don't find them good because they hide the > purpose the defined mechanism and make explanations more difficult. I > was unable to attend the meeting in Chicago, so I miss the reasons for > neutral instead of mnemonic names. What's the motivation behind this, in > particular for the lower PCN threshold? >=20 > Regards, >=20 > Michael >=20 >=20 > philip.eardley@bt.com wrote: > > > > Hi, > > > > I'm starting to do the mods in order to create > > draft-ietf-pcn-architecture-00, based on > > draft-eardley-pcn-architecture-00. > > > > One of the things is to adapt the PCN terminology. The consensus at > > the WG in Chicago was to move to names that are more 'neutral' and to > > use names for marking that reflect how the marking is done (rather > > than what it is trying to achieve). I think that PCN-upper-rate & > > PCN-lower-rate, and threshold-marking and excess-rate-marking were > > mentioned. > > > > A copy and paste of the definitions isn't quite possible, are the > > following are OK? I also tried to take account of Bob's review comment > > (25 july on the list) that we shouldn't use "rate" in the definitions > > loosely. > > > > * PCN-lower-rate: a reference rate configured for each link in the > > PCN-domain, which is lower than the PCN-upper-rate. It is used by an > > algorithm that determines whether a packet should be PCN-marked with a > > first encoding > > > > * PCN-upper-rate: a reference rate configured for each link in the > > PCN-domain, which is higher than the PCN-lower-rate. It is used by an > > algorithm that determines whether a packet should be PCN-marked with a > > second encoding. > > > > * Threshold-marking: a PCN-marking algorithm such that all PCN-traffic > > is marked if the PCN-traffic exceeds a particular rate (either the > > PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the > > intent of the algorithm rather than its instantaneous behaviour, since > > the rate measured at a particular moment depends on the algorithm, its > > implementation and the traffic's variance as well as its rate > > > > * Excess-rate-marking: a PCN-marking algorithm such that the amount of > > PCN-traffic that is PCN-marked is equal to the amount that exceeds a > > particular rate (either the PCN-lower-rate or PCN-upper-rate). NOTE: > > The definition reflects the intent of the algorithm rather than its > > instantaneous behaviour, since the rate measured at a particular > > moment depends on the algorithm, its implementation and the traffic's > > variance as well as its rate > > > > * PCN-marking: either threshold-marking or excess-rate-marking > > > > {if necessary we can define: PCN-lower-rate-marking and > > PCN-upper-rate-marking} > > > > I'll remove the term ECN-marking, which is unnecessary. > > > > What do you reckon? > > > > Best wishes, > > > > phil > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > >=20 > -- > 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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 07 04:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIKZo-0007ox-Go; Tue, 07 Aug 2007 04:38:04 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIKZn-0007or-Di for pcn-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 04:38:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIKZm-0007oj-VN for pcn@ietf.org; Tue, 07 Aug 2007 04:38:03 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIKZl-0003sj-7G for pcn@ietf.org; Tue, 07 Aug 2007 04:38:02 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 09:37:59 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Date: Tue, 7 Aug 2007 09:37:59 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC391@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Thread-Index: AcfOTJNiDbXXskhTRKOfZp0Z2OHPEQKgOrjQ From: To: X-OriginalArrivalTime: 07 Aug 2007 08:37:59.0773 (UTC) FILETIME=[42BA80D0:01C7D8CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Bob, all Re your comment > * WG process management > A lot of WG process management text, esp in S.3, but also the list of > possible flow termination mechanisms in S.4. All instances hilited in > magenta in the review at the above URL. > See separate mail about this to the PCN WG chairs (cc PCN list) > Subject: How to discuss WG scoping decisions in an RFC? There was no response, I think, on this point of your email. My plan is to be lazy and ignore this comment until consensus that something should be done! However, if others agree with bob please shout and I'll try and handle it in the next update (ie after the one that'll be out later this week). If you shout, please could you point to an rfc that handles this successfully (ie talks about WG scope restrictions, how they might might be loosened after re-chartering...) so I get an idea what to do! Thanks, phil > -----Original Message----- > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R > Sent: 25 July 2007 00:44 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 > Phil and all the authors of this PCN architecture draft, >=20 > Like Lars, I'd like to congratulate you all on such a mature first draft, > and on managing to encompass many different views we have seen from > various > people without making the thing an uncontrollable monster full of options > and choices. >=20 > I just read it all through and my review comments are given below. >=20 > Also see > t-eardley-pcn-architecture-00_rvw_bb.pdf> > for suggested minor text changes. >=20 > I haven't supplied text for more major changes inline below until the > authors agree with the need for change. But then I can supply text if > required. >=20 > At 16:59 28/06/2007, philip.eardley@bt.com wrote: > >Hi all, > > > >Just a reminder that all comments on this draft would be great. It aims > >to describe the PCN architecture, in light of the PCN WG's Charter & its > >Milestone of an Info doc on 'Flow Admission and Termination Architecture > >within a Diffserv Domain' (due Nov 07). >=20 > General comments: >=20 > * WG process management > A lot of WG process management text, esp in S.3, but also the list of > possible flow termination mechanisms in S.4. All instances hilited in > magenta in the review at the above URL. > See separate mail about this to the PCN WG chairs (cc PCN list) > Subject: How to discuss WG scoping decisions in an RFC? >=20 > * Choices vs decisions > I believe an architecture doc should say where one decision is required or > where multiple options are reasonable. Currently, the arch is good at > laying out the design space, but I'd like us to try to say which choices > have to be made by the IETF, which should be left to vendors and which > left > to operators. >=20 > >S1 Introduction. > >This is quite short. If desired, it could be boosted with a general > >explanation of where PCN fits into the picture of QoS and how it's > >evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01) >=20 > * Clarify that a packet might encounter more than one PCN domain along its > path, each being a separate admission control hop. >=20 > * Clarify that a "Diffserv domain" may be multiple concatenated autonomous > systems, but in this draft they are assumed to trust each other and have > identical configuration. >=20 > >S2 Terminology > >In the "Editor's note" are 3 alternative terms that some of the authors > >preferred. >=20 > * ECN _and_ PCN marking? >=20 > " o Configured-termination-rate: [...] > Normally it is configured to be less than > the maximum rate at which PCN-traffic can be forwarded on the > link, so that termination-marking occurs before any significant > queuing, ECN-marking or loss of PCN-packets. > " >=20 > The above text implies (to me) that a PCN-interior router might do PCN > marking _and_ also ECN marking just before drop. That also imposes a > requirement on the encoding to be able to carry either in the same field. > I don't think the authors meant either of these implications. So > somewhere, > the relation between PCN & ECN marking should be stated. >=20 > Although this is perhaps too detailed for the architecture, I suggest that > any need for ECN marking on the same path but outside the PCN domain(s) > should be handled by tunnelling across the PCN domain, with a non-PCN DSCP > in the inner header (that turns on the RFC3168 meaning of its ECN field) > and a PCN DSCP in the outer. >=20 > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. >=20 > The unintended implication that all packets are either marked or not > marked > should also be carefully avoided. The draft needs to say explicitly that > "Admission (or Termination) marking will be an encoding of some > combination > of codepoints in the IP header to signal a varying fractional number from > a > path of PCN-interior-nodes to a PCN-egress-node" >=20 > * inelastic > Do you think we should define "inelastic" or is this a well-known IETF > term? We could refer to [Shenker95], which I think was the first to define > the term. Or is there an RFC that defines this (hopefully with ref to > Shenker)? >=20 > Scott Shenker, "Fundamental Design Issues for the Future Internet", In: > IEEE Journal on Selected Areas in Communications 13 (7) pp. 1176--1188 > (1995). >=20 >=20 > >S3 Assumptions and constraints on scope > >These are the 4 things mentioned in the Charter, plus some explanation > >of them. Are they clear? Also we mention some of the ways that a future > >revised Charter might look at overcoming some of the > >constraints/assumptions; is this sub-section at the right depth? >=20 > * Are all the scoping assumptions equal relaxable? >=20 > Just a thought: might it be worth giving an indication of which > assumptions > are likely to be hard or impossible to relax and which not (e.g. I think > the aggregation assumption is implicit to all MBAC (measurement-based Adm > Ctrl). Also inelasticity is fairly fundamental - you don't need admission > control if flows aren't inelastic. >=20 > This would affect the last para, which implies all the assumptions might > be > relaxed one day. >=20 > >S4 High-level functional architecture > >We have tried to write this section (and the following ones) so that it > >fits all the various proposals there've been for PCN mechanisms. Does > >this make the section too wishy-washy or too hard to understand? Should > >it include some comparison of the different mechanisms proposed > >(PCN-interior-node marking algorithms & PCN-boundary-node reactions)? >=20 > * Functional or topological? > Is it intentional that the high level functions are classified by which > type of node does them in 3 cases and what function is to be done in the > others? Would it be possible to define functions in the abstract first, > then say which functions have to be implemented on certain types of nodes? > Or does this just make it unnecessarily incomprehensible? >=20 > Gaps: > 1/ Discuss which PCN node needs to know the IP address of which other PCN > node in different configurations. And state requirements this implies on > the signalling protocol, or on configuration. > Minimally, only the egress needs to know the ingress address. In > centralised admission control scenarios, either the egress or the ingress > or both might need to be configured with a central address. >=20 > 2/ Related to knowing addresses of other nodes: When a PCN node receives a > message claiming to be from another PCN node, to validate the msg is > indeed > from the node it claims to be, are there any different issues that PCN > raises relative to typical reservation signalling systems? > draft-lefaucheur-rsvp-ecn-01 (expired) contains a good deal of text on > this > issue that should be generalised into this arch doc. >=20 > >S5 Detailed Functional architecture > >Is this a reasonable description of the extra functionality that PCN > >requires on various nodes in the PCN-domain? Is it the right way to > >split up the description? For clarity / help reader's understanding, > >should there be some specific examples of how functionality might be > >distributed (eg "if you followed the deployment model in > >draft-briscoe-tsvwg-cl-architecture-04, then this measurement is made at > >the PCN-egress-node, communicated to the PCN-ingress-nodes which makes > >the admission decision; etc.") >=20 > S.5.5 Probing functions >=20 > If we are going to consider a case where the ingress has prior knowledge > of > which egress is associated with which destination address (e.g. with a > separate signalling routing table as discussed in NSIS, or if the > signalling protocol goes receiver-sender-receiver), then the ingress could > know that it has no reservations with that egress as soon as a reservation > request arrives, so it can unilaterally start probling. >=20 > S.5.6 Flow Termination Functions >=20 > The text seems to assume the egress makes the decision on which flows to > lose and tells the ingress. In cl-architecture (for instance) the egress > meters, feeds back the measurement to the ingress, which meters the load > it > is forwarding and then the ingress calculates how much traffic to > terminate, and either chooses the flows itself, or asks a central node to > choose. >=20 > I think there has to be metering at both boundaries otherwise we can't > work > out how much traffic has been dropped (as well as termination marked). The > decision might be at either (but in cl-architecture we had good reasons > for > choosing the ingress because it has the most recent knowledge about load > (given flows might be being abandoned by users very quickly and/or added > very quickly during a disaster). >=20 > Other more incremental mechanisms have now been defined that don't > calculate how much load to shed in one pass, but keep trying. Have we > abandonned the earlier approach? >=20 > Whatever, I think a feedback function is missing between the boundary > nodes. >=20 > >S6 Design goals and challenges > >This briefly describes some open issues, taken from > >briscoe-tsvwg-cl-architecture. Are there other ones that should be > >mentioned? Is the problem description at the right level of depth? > >Should we discuss various possible solutions to these problems? >=20 > I get the feeling we need a doc specifically on ECMP solutions? >=20 > >S7 Deployment scenarios > >Briefly describes some deployment scenarios for pcn? is this at the > >right level of depth? >=20 > Just a thought - I felt this section would have been better earlier. >=20 > >S8 Operations and Management > >This section was written in response to the Charter saying that the > >architecture document should include security, manageability and > >operational considerations. The draft addresses this by providing some > >thoughts under the FCAPS headings: OAM of Faults, Configuration, > >Accounting, Performance and Security? Is this the right way of > >structuring it - does it cover the right set of topics? Is the text at > >the right level? - eg should it also have a detailed set of parameters > >that would be available for configuration? >=20 > * Don't think this is Fault OAM? > Echoing what someone else (I forget who) said on the list, Fault OAM isn't > really about how the control system recovers from failures (that's > control), it's how to tell the management system/manual operator that you > have recovered from a failure (or not). >=20 > Also, we should cover faults other than node or link failures. E.g. a > wrongly configured address in a node, or a wrong address given in a > singalling protocol, or a wrongly configured parameter in a queueing algo. > Etc. >=20 > * Config OAM: Add: > - level of AM that leads to denying new admissions. > - config paramteres that control distribution of functions? >=20 > * Don't think this is Performance OAM? > I think Perf OAM is about monitoring performance at run-time, not > characterising performance at design time. >=20 > * Don't think this is Security OAM? > Again, as someone said, security OAM is finding out about security > breaches > or near-misses at run-time, not identifying security flaws in the design, > which is security the considerations section. >=20 > * Security Considerations Gaps: > - PCN marking selectively applied to certain flows, rather than randomly > by > interior node. > - The statement about DoS attacks is a requirement with no pointers to the > detailed DOS issues, or any discussion of best practice design. I could > supply text here (among many other things to do!) > - ref to hop-by-hop signalling authentication [RFC2747 for RSVP] and the > new recently posted draft to tsvwg on group keying for RSVP authentication > . I haven't read > it > yet, but on a scan it's as relevant as RFC2747. >=20 >=20 > Phew... that's all for now. >=20 >=20 > Bob >=20 >=20 > >An overall question is whether the draft should have more comparison of > >the options (pros/cons) for various aspects. > > > >I aim to edit another version of the draft before the ietf (but maybe > >not before the deadline as I'm on hols next week). > > > >Thanks! > >Phil/ >=20 > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 07 09:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOoA-0000Se-Ve; Tue, 07 Aug 2007 09:09:10 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIOo9-0000SY-6N for pcn-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 09:09:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOo8-0000SQ-Pz for pcn@ietf.org; Tue, 07 Aug 2007 09:09:08 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIOo6-0005Mm-Ta for pcn@ietf.org; Tue, 07 Aug 2007 09:09:08 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 14:09:06 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Date: Tue, 7 Aug 2007 14:09:05 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC393@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <00a001c7c530$018b0aa0$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Thread-Index: AcfFMJne4hNxGHFbSDGtK9TcqAvjCATwmUMQ From: To: , X-OriginalArrivalTime: 07 Aug 2007 13:09:06.0066 (UTC) FILETIME=[2231D720:01C7D8F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Tina delayed follow-up (now I'm editing draft) My proposal: I'm going to handle this by simplifying the para so it reads: The decision is made at a centralised node, which requires that the PCN-egress-node signals to the centralised node about the required "measurements of PCN-traffic", and that the centralised node signals to the PCN-ingress-node about the decision about admission control. It would ... The reason is that the bullet a few lines earlier says=20 Make decision about admission - [cut] As well as the PCN measurements, the decision takes account of policy and application layer requirements. Ie we don't need to repeat this again. Hopefully ok? phil > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: 13 July 2007 10:27 > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 > Sorry, forgot to delete "policy and". They should be display as below. >=20 > > The decision is made at a centralised node, which requires that > > the PCN-egress-node signals to the centralised node about "the > > required measurements of PCN-traffic" (and that the centralised > > node learns about application layer requirements), and > > that the centralised node signals to the PCN-ingress-node about > > the decision about admission control and relative QoS policies. It > would > > be possible for > > the centralised node to be one of the PCN-boundary-nodes, when > > clearly the signalling would sometimes be replaced by a message > > internal to the node. >=20 > B. R. > Tina >=20 > ----- Original Message ----- > From: "Tina TSOU" > To: ; > Sent: Friday, July 13, 2007 4:39 PM > Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 >=20 > > Hi Phil, > > Thanks:) > > > > Wrt to section 5.4, I suggest as below. > > /*delete "policy and"*/ > > /*add "and relative QoS policies"*/ > > The decision is made at a centralised node, which requires that > > the PCN-egress-node signals to the centralised node about "the > > required measurements of PCN-traffic" (and that the centralised > > node learns about policy and application layer requirements), and > > that the centralised node signals to the PCN-ingress-node about > > the decision about admission control and relative QoS policies. It > would > > be possible for > > the centralised node to be one of the PCN-boundary-nodes, when > > clearly the signalling would sometimes be replaced by a message > > internal to the node. > > > > B. R. > > Tina > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Thursday, July 12, 2007 7:45 PM > > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > > > > > Tina > > > > Thanks > > > > Your changes in S1 & S2 seem good to me. > > > > You made a comment in S5.4, but didn't suggest a text change. I think > > your comment doesn't need any change to S4 (ie it's already covered > > either in S5.4 [option of centralised node making decision] or earlier > > [ingress node doing policing]. is that ok? > > > > Thanks > > Phil/ > > > >> -----Original Message----- > >> From: Tina TSOU [mailto:tena@huawei.com] > >> Sent: 11 July 2007 04:56 > >> To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > >> Subject: Re: [PCN] Fwd: I-D > > ACTION:draft-eardley-pcn-architecture-00.txt > >> > >> Hi Phil, > >> I made some proposed specific changes with revised mark together with > >> comments in the attachment. > >> Hope it helps:) > >> > >> B. R. > >> Tina > >> > >> ----- Original Message ----- > >> From: > >> To: ; > >> Sent: Monday, July 09, 2007 8:16 PM > >> Subject: RE: [PCN] Fwd: I-D > > ACTION:draft-eardley-pcn-architecture-00.txt > >> > >> > >> Tina > >> Thanks > >> I'm not sure I completely understand your comments, sorry. > >> > >> Is the problem that at the moment the draft only describes the Pull > >> model and not the Push model? Which lines of text need changing? > >> (somewhere in Section 5.4 or section 7 or somewhere else?) > >> > >> Thanks! > >> phil > >> > >> > -----Original Message----- > >> > From: Tina TSOU [mailto:tena@huawei.com] > >> > Sent: 02 July 2007 04:38 > >> > To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > >> > Subject: Re: [PCN] Fwd: I-D > >> ACTION:draft-eardley-pcn-architecture-00.txt > >> > > >> > Hi all, > >> > One of the scenarios I am suggesting is below. > >> > > >> > Even in Pull mode, application layer QoS request (via RSVP) should > > be > >> also > >> > sent from ingress to the centralized node, in centralized node the > >> policy > >> > is > >> > generated, then the decision is made, and then delivers to the > > Ingress > >> to > >> > enforce. I was not saying that the policy is directly generated in > > the > >> > Ingress. Even the rather that Push mode should be also taken into > >> account. > >> > > >> > I.e. we define the centralized node locates in the transport control > >> > layer; > >> > the Ingress and Egress locate in transport layer. For the > >> implementation > >> > of > >> > physical entities, they are service policy server and PCN-enabled > >> router > >> > respectively. > >> > > >> > The centralized node is policy decision node, it should be based on > >> (1) > >> > Egress measurement result (2) operator's policies (could be > > configured > >> in > >> > the centralized node) (3) QoS request coming from the application > >> layer > >> > (PUSH or PULL mode), to make the decision, and decide which flows > >> should > >> > be > >> > admitted or reject, which flows should be stopped temperately or > >> > downgraded, > >> > which flows should be done policing. The generated policy should be > >> sent > >> > to > >> > ingress for enforcement. > >> > > >> > Ingress is the policy enforcement point, it based on the policy > >> delivered > >> > by > >> > the centralized node, (1) it allows flow pass or filter flow, (2) > > for > >> the > >> > flows allowed to pass, it makes policing and coloring based on the > >> policy. > >> > > >> > Referrence: > >> > QoS "Push" Model: model where the centralised node "pushes" traffic > >> > policies > >> > to the transport functions to enforce its policy decisions. > >> > NOTE: In this model, the CPE does not itself support native > >> application > >> > independent QoS procedures. > >> > QoS "Pull" Model: model where, upon request from the transport > >> processing > >> > functions, the centralised node provides traffic policies to the > >> transport > >> > processing functions. The request from the transport processing > >> functions > >> > may itself, for example, be triggered by path-coupled requests > > coming > >> from > >> > user equipment and/or transport network elements. > >> > > >> > > >> > B. R. > >> > Tina > >> > > >> > ----- Original Message ----- > >> > From: > >> > To: > >> > Sent: Thursday, June 28, 2007 11:59 PM > >> > Subject: RE: [PCN] Fwd: I-D > >> ACTION:draft-eardley-pcn-architecture-00.txt > >> > > >> > > >> > Hi all, > >> > > >> > Just a reminder that all comments on this draft would be great. It > >> aims > >> > to describe the PCN architecture, in light of the PCN WG's Charter & > >> its > >> > Milestone of an Info doc on 'Flow Admission and Termination > >> Architecture > >> > within a Diffserv Domain' (due Nov 07). > >> > > >> > S1 Introduction. > >> > This is quite short. If desired, it could be boosted with a general > >> > explanation of where PCN fits into the picture of QoS and how it's > >> > evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01) > >> > > >> > S2 Terminology > >> > In the "Editor's note" are 3 alternative terms that some of the > >> authors > >> > preferred. > >> > > >> > S3 Assumptions and constraints on scope > >> > These are the 4 things mentioned in the Charter, plus some > > explanation > >> > of them. Are they clear? Also we mention some of the ways that a > >> future > >> > revised Charter might look at overcoming some of the > >> > constraints/assumptions; is this sub-section at the right depth? > >> > > >> > S4 High-level functional architecture > >> > We have tried to write this section (and the following ones) so that > >> it > >> > fits all the various proposals there've been for PCN mechanisms. > > Does > >> > this make the section too wishy-washy or too hard to understand? > >> Should > >> > it include some comparison of the different mechanisms proposed > >> > (PCN-interior-node marking algorithms & PCN-boundary-node > > reactions)? > >> > > >> > S5 Detailed Functional architecture > >> > Is this a reasonable description of the extra functionality that PCN > >> > requires on various nodes in the PCN-domain? Is it the right way to > >> > split up the description? For clarity / help reader's understanding, > >> > should there be some specific examples of how functionality might be > >> > distributed (eg "if you followed the deployment model in > >> > draft-briscoe-tsvwg-cl-architecture-04, then this measurement is > > made > >> at > >> > the PCN-egress-node, communicated to the PCN-ingress-nodes which > > makes > >> > the admission decision; etc.") > >> > > >> > S6 Design goals and challenges > >> > This briefly describes some open issues, taken from > >> > briscoe-tsvwg-cl-architecture. Are there other ones that should be > >> > mentioned? Is the problem description at the right level of depth? > >> > Should we discuss various possible solutions to these problems? > >> > > >> > S7 Deployment scenarios > >> > Briefly describes some deployment scenarios for pcn? is this at the > >> > right level of depth? > >> > > >> > S8 Operations and Management > >> > This section was written in response to the Charter saying that the > >> > architecture document should include security, manageability and > >> > operational considerations. The draft addresses this by providing > > some > >> > thoughts under the FCAPS headings: OAM of Faults, Configuration, > >> > Accounting, Performance and Security? Is this the right way of > >> > structuring it - does it cover the right set of topics? Is the text > > at > >> > the right level? - eg should it also have a detailed set of > > parameters > >> > that would be available for configuration? > >> > > >> > An overall question is whether the draft should have more comparison > >> of > >> > the options (pros/cons) for various aspects. > >> > > >> > I aim to edit another version of the draft before the ietf (but > > maybe > >> > not before the deadline as I'm on hols next week). > >> > > >> > Thanks! > >> > Phil/ > >> > > >> > > >> > > -----Original Message----- > >> > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > >> > > Sent: 22 June 2007 04:38 > >> > > To: pcn@ietf.org > >> > > Subject: [PCN] Fwd: I-D > > ACTION:draft-eardley-pcn-architecture-00.txt > >> > > > >> > > Hi all: > >> > > Please see the attached E-Mail on the posting of the PCN > >> Architecture > >> > > draft. > >> > > On behave of the editor of this draft: Phil, and the co-authors of > >> > this > >> > > draft, > >> > > we would like to request for reviews and comments of this draft > > and > >> > > welcome > >> > > any comments for improvements. > >> > > > >> > > Please send your comments/discussions of this draft on the PCN > > list. > >> > > > >> > > Thank you for your interest and review of this draft! > >> > > -- Kwok on behave of the co-authors of this draft -- > >> > > > >> > > > >> > > >To: i-d-announce@ietf.org > >> > > >Cc: > >> > > >From: Internet-Drafts@ietf.org > >> > > >Date: Thu, 21 Jun 2007 15:50:02 -0400 > >> > > >X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > >> > > >Subject: I-D ACTION:draft-eardley-pcn-architecture-00.txt > >> > > >X-BeenThere: i-d-announce@ietf.org > >> > > >X-Mailman-Version: 2.1.5 > >> > > >Reply-To: internet-drafts@ietf.org > >> > > >List-Id: i-d-announce.ietf.org > >> > > >List-Unsubscribe: > >> > , > >> > > > > >> > > >List-Archive: > >> > > >List-Post: > >> > > >List-Help: = > >> > > >List-Subscribe: > >> > , > >> > > > > >> > > >X-Spam-Tests: = FORGED_RCVD_HELO=3D0.05,MIME_BOUND_NEXTPART=3D0.106, > >> > > > NO_REAL_NAME=3D0.178,TO_CC_NOT_NORTEL=3D1,URIBL_MANURI=3D4 > >> > > >X-Spam-Score: 5.3 > >> > > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on > >> > > ecarhea1.nortel.com > >> > > >X-DNSBL-Score: -50 > >> > > >X-DNSBL-Servers: bl.nortel.com > >> > > >X-SMTP-HELO: megatron.ietf.org > >> > > >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org > >> > > >X-SMTP-RCPT-TO: > >> > > > >> > > >> > >>kboyle@nortel.com,bstucker@nortel.com,balles@nortel.com,bharrath@norte l > >> > .c > >> > > > >> > > >> > > om,babiarz@nortel.com,audet@nortel.com,aceler@nortel.com,simmonds@nortel > >> > .c > >> > > > >> > > >> > > om,huiwc@nortel.com,amuhanna@nortel.com,mchen@nortel.com,khchan@nortel.c > >> > om > >> > > >X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145] > >> > > >X-SMTP-REASON: PASSED > >> > > >X-SMTP-ID: 1182455563.14011407 > >> > > >X-OriginalArrivalTime: 21 Jun 2007 19:52:44.0828 (UTC) > >> > > >FILETIME=3D[BC4965C0:01C7B43D] > >> > > > > >> > > >A New Internet-Draft is available from the on-line > > Internet-Drafts > >> > > >directories. > >> > > > > >> > > > > >> > > > Title : Pre-Congestion Notification > > Architecture > >> > > > Author(s) : P. Eardley, et al. > >> > > > Filename : draft-eardley-pcn-architecture-00.txt > >> > > > Pages : 27 > >> > > > Date : 2007-6-21 > >> > > > > >> > > > The purpose of this document is to describe a general > >> > architecture > >> > > > for flow admission and termination based on aggregated (pre-) > >> > > > congestion information in order to protect the quality of > >> service > >> > of > >> > > > established inelastic flows within a single DiffServ domain. > >> > > > > >> > > > > >> > > >A URL for this Internet-Draft is: > >> > > > >> > > >> > >>http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00. t > >> > xt > >> > > > > >> > > >To remove yourself from the I-D Announcement list, send a message > >> to > >> > > >i-d-announce-request@ietf.org with the word unsubscribe in the > > body > >> > of > >> > > >the message. > >> > > >You can also visit > >> > https://www1.ietf.org/mailman/listinfo/I-D-announce > >> > > >to change your subscription settings. > >> > > > > >> > > >Internet-Drafts are also available by anonymous FTP. Login with > > the > >> > > >username "anonymous" and a password of your e-mail address. After > >> > > >logging in, type "cd internet-drafts" and then > >> > > >"get draft-eardley-pcn-architecture-00.txt". > >> > > > > >> > > >A list of Internet-Drafts directories can be found in > >> > > >http://www.ietf.org/shadow.html > >> > > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > > > >> > > >Internet-Drafts can also be obtained by e-mail. > >> > > > > >> > > >Send a message to: > >> > > > mailserv@ietf.org. > >> > > >In the body type: > >> > > > "FILE > >> > /internet-drafts/draft-eardley-pcn-architecture-00.txt". > >> > > > > >> > > >NOTE: The mail server at ietf.org can return the document in > >> > > > MIME-encoded form by using the "mpack" utility. To use > >> this > >> > > > feature, insert the command "ENCODING mime" before the > >> > "FILE" > >> > > > command. To decode the response(s), you will need > >> "munpack" > >> > or > >> > > > a MIME-compliant mail reader. Different MIME-compliant > >> mail > >> > > readers > >> > > > exhibit different behavior, especially when dealing with > >> > > > "multipart" MIME messages (i.e. documents which have > > been > >> > split > >> > > > up into multiple messages), so check your local > >> > documentation on > >> > > > how to manipulate these messages. > >> > > > > >> > > >Below is the data which will enable a MIME compliant mail reader > >> > > >implementation to automatically retrieve the ASCII version of the > >> > > >Internet-Draft. > >> > > > > >> > > >Content-Type: text/plain > >> > > >Content-ID: <2007-6-21120238.I-D@ietf.org> > >> > > > > >> > > >ENCODING mime > >> > > >FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt > >> > > > > >> > > > > >> > > > >> >> > > 00.txt> > >> > > >_______________________________________________ > >> > > >I-D-Announce mailing list > >> > > >I-D-Announce@ietf.org > >> > > >https://www1.ietf.org/mailman/listinfo/i-d-announce > >> > > > >> > > > >> > > > >> > > > >> > > _______________________________________________ > >> > > PCN mailing list > >> > > PCN@ietf.org > >> > > https://www1.ietf.org/mailman/listinfo/pcn > >> > > >> > > >> > _______________________________________________ > >> > PCN mailing list > >> > PCN@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 08 05:41:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIi2w-0005zb-Ll; Wed, 08 Aug 2007 05:41:42 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIi2r-0005ro-2j for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 05:41:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIi2q-0005qK-77 for pcn@ietf.org; Wed, 08 Aug 2007 05:41:36 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIi2n-00026n-2v for pcn@ietf.org; Wed, 08 Aug 2007 05:41:36 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMG00NXI87L0K@szxga03-in.huawei.com> for pcn@ietf.org; Wed, 08 Aug 2007 17:40:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMG00MZB87IGX@szxga03-in.huawei.com> for pcn@ietf.org; Wed, 08 Aug 2007 17:40:33 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMG00KMG87H3N@szxml03-in.huawei.com> for pcn@ietf.org; Wed, 08 Aug 2007 17:40:29 +0800 (CST) Date: Wed, 08 Aug 2007 17:40:29 +0800 From: Tina TSOU Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt To: pcn@ietf.org, philip.eardley@bt.com Message-id: <010001c7d9a0$2859d880$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC393@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d4673ea769cc9931269061744af205ce Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, Sounds excellent:) A small comment is below. In this scenario, if Egress does not need to reply any message to Ingress, it is more reasonable to let the Egress report to the centralized node. If Egress still needs to replay some message to Ingress, a case which lets the Ingress report to the Centralized node could be added. And I could not remember the scenario that the Egress must reply to Ingress. If someone remembers, would you remind me? :) B. R. Tina ----- Original Message ----- From: To: ; Sent: Tuesday, August 07, 2007 9:09 PM Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Tina delayed follow-up (now I'm editing draft) My proposal: I'm going to handle this by simplifying the para so it reads: The decision is made at a centralised node, which requires that the PCN-egress-node signals to the centralised node about the required "measurements of PCN-traffic", and that the centralised node signals to the PCN-ingress-node about the decision about admission control. It would ... The reason is that the bullet a few lines earlier says Make decision about admission - [cut] As well as the PCN measurements, the decision takes account of policy and application layer requirements. Ie we don't need to repeat this again. Hopefully ok? phil > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: 13 July 2007 10:27 > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > Sorry, forgot to delete "policy and". They should be display as below. > > > The decision is made at a centralised node, which requires that > > the PCN-egress-node signals to the centralised node about "the > > required measurements of PCN-traffic" (and that the centralised > > node learns about application layer requirements), and > > that the centralised node signals to the PCN-ingress-node about > > the decision about admission control and relative QoS policies. It > would > > be possible for > > the centralised node to be one of the PCN-boundary-nodes, when > > clearly the signalling would sometimes be replaced by a message > > internal to the node. > > B. R. > Tina > > ----- Original Message ----- > From: "Tina TSOU" > To: ; > Sent: Friday, July 13, 2007 4:39 PM > Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > > > Hi Phil, > > Thanks:) > > > > Wrt to section 5.4, I suggest as below. > > /*delete "policy and"*/ > > /*add "and relative QoS policies"*/ > > The decision is made at a centralised node, which requires that > > the PCN-egress-node signals to the centralised node about "the > > required measurements of PCN-traffic" (and that the centralised > > node learns about policy and application layer requirements), and > > that the centralised node signals to the PCN-ingress-node about > > the decision about admission control and relative QoS policies. It > would > > be possible for > > the centralised node to be one of the PCN-boundary-nodes, when > > clearly the signalling would sometimes be replaced by a message > > internal to the node. > > > > B. R. > > Tina > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Thursday, July 12, 2007 7:45 PM > > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > > > > > Tina > > > > Thanks > > > > Your changes in S1 & S2 seem good to me. > > > > You made a comment in S5.4, but didn't suggest a text change. I think > > your comment doesn't need any change to S4 (ie it's already covered > > either in S5.4 [option of centralised node making decision] or earlier > > [ingress node doing policing]. is that ok? > > > > Thanks > > Phil/ > > > >> -----Original Message----- > >> From: Tina TSOU [mailto:tena@huawei.com] > >> Sent: 11 July 2007 04:56 > >> To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > >> Subject: Re: [PCN] Fwd: I-D > > ACTION:draft-eardley-pcn-architecture-00.txt > >> > >> Hi Phil, > >> I made some proposed specific changes with revised mark together with > >> comments in the attachment. > >> Hope it helps:) > >> > >> B. R. > >> Tina > >> > >> ----- Original Message ----- > >> From: > >> To: ; > >> Sent: Monday, July 09, 2007 8:16 PM > >> Subject: RE: [PCN] Fwd: I-D > > ACTION:draft-eardley-pcn-architecture-00.txt > >> > >> > >> Tina > >> Thanks > >> I'm not sure I completely understand your comments, sorry. > >> > >> Is the problem that at the moment the draft only describes the Pull > >> model and not the Push model? Which lines of text need changing? > >> (somewhere in Section 5.4 or section 7 or somewhere else?) > >> > >> Thanks! > >> phil > >> > >> > -----Original Message----- > >> > From: Tina TSOU [mailto:tena@huawei.com] > >> > Sent: 02 July 2007 04:38 > >> > To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > >> > Subject: Re: [PCN] Fwd: I-D > >> ACTION:draft-eardley-pcn-architecture-00.txt > >> > > >> > Hi all, > >> > One of the scenarios I am suggesting is below. > >> > > >> > Even in Pull mode, application layer QoS request (via RSVP) should > > be > >> also > >> > sent from ingress to the centralized node, in centralized node the > >> policy > >> > is > >> > generated, then the decision is made, and then delivers to the > > Ingress > >> to > >> > enforce. I was not saying that the policy is directly generated in > > the > >> > Ingress. Even the rather that Push mode should be also taken into > >> account. > >> > > >> > I.e. we define the centralized node locates in the transport control > >> > layer; > >> > the Ingress and Egress locate in transport layer. For the > >> implementation > >> > of > >> > physical entities, they are service policy server and PCN-enabled > >> router > >> > respectively. > >> > > >> > The centralized node is policy decision node, it should be based on > >> (1) > >> > Egress measurement result (2) operator's policies (could be > > configured > >> in > >> > the centralized node) (3) QoS request coming from the application > >> layer > >> > (PUSH or PULL mode), to make the decision, and decide which flows > >> should > >> > be > >> > admitted or reject, which flows should be stopped temperately or > >> > downgraded, > >> > which flows should be done policing. The generated policy should be > >> sent > >> > to > >> > ingress for enforcement. > >> > > >> > Ingress is the policy enforcement point, it based on the policy > >> delivered > >> > by > >> > the centralized node, (1) it allows flow pass or filter flow, (2) > > for > >> the > >> > flows allowed to pass, it makes policing and coloring based on the > >> policy. > >> > > >> > Referrence: > >> > QoS "Push" Model: model where the centralised node "pushes" traffic > >> > policies > >> > to the transport functions to enforce its policy decisions. > >> > NOTE: In this model, the CPE does not itself support native > >> application > >> > independent QoS procedures. > >> > QoS "Pull" Model: model where, upon request from the transport > >> processing > >> > functions, the centralised node provides traffic policies to the > >> transport > >> > processing functions. The request from the transport processing > >> functions > >> > may itself, for example, be triggered by path-coupled requests > > coming > >> from > >> > user equipment and/or transport network elements. > >> > > >> > > >> > B. R. > >> > Tina > >> > > >> > ----- Original Message ----- > >> > From: > >> > To: > >> > Sent: Thursday, June 28, 2007 11:59 PM > >> > Subject: RE: [PCN] Fwd: I-D > >> ACTION:draft-eardley-pcn-architecture-00.txt > >> > > >> > > >> > Hi all, > >> > > >> > Just a reminder that all comments on this draft would be great. It > >> aims > >> > to describe the PCN architecture, in light of the PCN WG's Charter & > >> its > >> > Milestone of an Info doc on 'Flow Admission and Termination > >> Architecture > >> > within a Diffserv Domain' (due Nov 07). > >> > > >> > S1 Introduction. > >> > This is quite short. If desired, it could be boosted with a general > >> > explanation of where PCN fits into the picture of QoS and how it's > >> > evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01) > >> > > >> > S2 Terminology > >> > In the "Editor's note" are 3 alternative terms that some of the > >> authors > >> > preferred. > >> > > >> > S3 Assumptions and constraints on scope > >> > These are the 4 things mentioned in the Charter, plus some > > explanation > >> > of them. Are they clear? Also we mention some of the ways that a > >> future > >> > revised Charter might look at overcoming some of the > >> > constraints/assumptions; is this sub-section at the right depth? > >> > > >> > S4 High-level functional architecture > >> > We have tried to write this section (and the following ones) so that > >> it > >> > fits all the various proposals there've been for PCN mechanisms. > > Does > >> > this make the section too wishy-washy or too hard to understand? > >> Should > >> > it include some comparison of the different mechanisms proposed > >> > (PCN-interior-node marking algorithms & PCN-boundary-node > > reactions)? > >> > > >> > S5 Detailed Functional architecture > >> > Is this a reasonable description of the extra functionality that PCN > >> > requires on various nodes in the PCN-domain? Is it the right way to > >> > split up the description? For clarity / help reader's understanding, > >> > should there be some specific examples of how functionality might be > >> > distributed (eg "if you followed the deployment model in > >> > draft-briscoe-tsvwg-cl-architecture-04, then this measurement is > > made > >> at > >> > the PCN-egress-node, communicated to the PCN-ingress-nodes which > > makes > >> > the admission decision; etc.") > >> > > >> > S6 Design goals and challenges > >> > This briefly describes some open issues, taken from > >> > briscoe-tsvwg-cl-architecture. Are there other ones that should be > >> > mentioned? Is the problem description at the right level of depth? > >> > Should we discuss various possible solutions to these problems? > >> > > >> > S7 Deployment scenarios > >> > Briefly describes some deployment scenarios for pcn? is this at the > >> > right level of depth? > >> > > >> > S8 Operations and Management > >> > This section was written in response to the Charter saying that the > >> > architecture document should include security, manageability and > >> > operational considerations. The draft addresses this by providing > > some > >> > thoughts under the FCAPS headings: OAM of Faults, Configuration, > >> > Accounting, Performance and Security? Is this the right way of > >> > structuring it - does it cover the right set of topics? Is the text > > at > >> > the right level? - eg should it also have a detailed set of > > parameters > >> > that would be available for configuration? > >> > > >> > An overall question is whether the draft should have more comparison > >> of > >> > the options (pros/cons) for various aspects. > >> > > >> > I aim to edit another version of the draft before the ietf (but > > maybe > >> > not before the deadline as I'm on hols next week). > >> > > >> > Thanks! > >> > Phil/ > >> > > >> > > >> > > -----Original Message----- > >> > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > >> > > Sent: 22 June 2007 04:38 > >> > > To: pcn@ietf.org > >> > > Subject: [PCN] Fwd: I-D > > ACTION:draft-eardley-pcn-architecture-00.txt > >> > > > >> > > Hi all: > >> > > Please see the attached E-Mail on the posting of the PCN > >> Architecture > >> > > draft. > >> > > On behave of the editor of this draft: Phil, and the co-authors of > >> > this > >> > > draft, > >> > > we would like to request for reviews and comments of this draft > > and > >> > > welcome > >> > > any comments for improvements. > >> > > > >> > > Please send your comments/discussions of this draft on the PCN > > list. > >> > > > >> > > Thank you for your interest and review of this draft! > >> > > -- Kwok on behave of the co-authors of this draft -- > >> > > > >> > > > >> > > >To: i-d-announce@ietf.org > >> > > >Cc: > >> > > >From: Internet-Drafts@ietf.org > >> > > >Date: Thu, 21 Jun 2007 15:50:02 -0400 > >> > > >X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > >> > > >Subject: I-D ACTION:draft-eardley-pcn-architecture-00.txt > >> > > >X-BeenThere: i-d-announce@ietf.org > >> > > >X-Mailman-Version: 2.1.5 > >> > > >Reply-To: internet-drafts@ietf.org > >> > > >List-Id: i-d-announce.ietf.org > >> > > >List-Unsubscribe: > >> > , > >> > > > > >> > > >List-Archive: > >> > > >List-Post: > >> > > >List-Help: > >> > > >List-Subscribe: > >> > , > >> > > > > >> > > >X-Spam-Tests: FORGED_RCVD_HELO=0.05,MIME_BOUND_NEXTPART=0.106, > >> > > > NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1,URIBL_MANURI=4 > >> > > >X-Spam-Score: 5.3 > >> > > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on > >> > > ecarhea1.nortel.com > >> > > >X-DNSBL-Score: -50 > >> > > >X-DNSBL-Servers: bl.nortel.com > >> > > >X-SMTP-HELO: megatron.ietf.org > >> > > >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org > >> > > >X-SMTP-RCPT-TO: > >> > > > >> > > >> > >>kboyle@nortel.com,bstucker@nortel.com,balles@nortel.com,bharrath@norte l > >> > .c > >> > > > >> > > >> > > om,babiarz@nortel.com,audet@nortel.com,aceler@nortel.com,simmonds@nortel > >> > .c > >> > > > >> > > >> > > om,huiwc@nortel.com,amuhanna@nortel.com,mchen@nortel.com,khchan@nortel.c > >> > om > >> > > >X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145] > >> > > >X-SMTP-REASON: PASSED > >> > > >X-SMTP-ID: 1182455563.14011407 > >> > > >X-OriginalArrivalTime: 21 Jun 2007 19:52:44.0828 (UTC) > >> > > >FILETIME=[BC4965C0:01C7B43D] > >> > > > > >> > > >A New Internet-Draft is available from the on-line > > Internet-Drafts > >> > > >directories. > >> > > > > >> > > > > >> > > > Title : Pre-Congestion Notification > > Architecture > >> > > > Author(s) : P. Eardley, et al. > >> > > > Filename : draft-eardley-pcn-architecture-00.txt > >> > > > Pages : 27 > >> > > > Date : 2007-6-21 > >> > > > > >> > > > The purpose of this document is to describe a general > >> > architecture > >> > > > for flow admission and termination based on aggregated (pre-) > >> > > > congestion information in order to protect the quality of > >> service > >> > of > >> > > > established inelastic flows within a single DiffServ domain. > >> > > > > >> > > > > >> > > >A URL for this Internet-Draft is: > >> > > > >> > > >> > >>http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00. t > >> > xt > >> > > > > >> > > >To remove yourself from the I-D Announcement list, send a message > >> to > >> > > >i-d-announce-request@ietf.org with the word unsubscribe in the > > body > >> > of > >> > > >the message. > >> > > >You can also visit > >> > https://www1.ietf.org/mailman/listinfo/I-D-announce > >> > > >to change your subscription settings. > >> > > > > >> > > >Internet-Drafts are also available by anonymous FTP. Login with > > the > >> > > >username "anonymous" and a password of your e-mail address. After > >> > > >logging in, type "cd internet-drafts" and then > >> > > >"get draft-eardley-pcn-architecture-00.txt". > >> > > > > >> > > >A list of Internet-Drafts directories can be found in > >> > > >http://www.ietf.org/shadow.html > >> > > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > > > >> > > >Internet-Drafts can also be obtained by e-mail. > >> > > > > >> > > >Send a message to: > >> > > > mailserv@ietf.org. > >> > > >In the body type: > >> > > > "FILE > >> > /internet-drafts/draft-eardley-pcn-architecture-00.txt". > >> > > > > >> > > >NOTE: The mail server at ietf.org can return the document in > >> > > > MIME-encoded form by using the "mpack" utility. To use > >> this > >> > > > feature, insert the command "ENCODING mime" before the > >> > "FILE" > >> > > > command. To decode the response(s), you will need > >> "munpack" > >> > or > >> > > > a MIME-compliant mail reader. Different MIME-compliant > >> mail > >> > > readers > >> > > > exhibit different behavior, especially when dealing with > >> > > > "multipart" MIME messages (i.e. documents which have > > been > >> > split > >> > > > up into multiple messages), so check your local > >> > documentation on > >> > > > how to manipulate these messages. > >> > > > > >> > > >Below is the data which will enable a MIME compliant mail reader > >> > > >implementation to automatically retrieve the ASCII version of the > >> > > >Internet-Draft. > >> > > > > >> > > >Content-Type: text/plain > >> > > >Content-ID: <2007-6-21120238.I-D@ietf.org> > >> > > > > >> > > >ENCODING mime > >> > > >FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt > >> > > > > >> > > > > >> > > > >> >> > > 00.txt> > >> > > >_______________________________________________ > >> > > >I-D-Announce mailing list > >> > > >I-D-Announce@ietf.org > >> > > >https://www1.ietf.org/mailman/listinfo/i-d-announce > >> > > > >> > > > >> > > > >> > > > >> > > _______________________________________________ > >> > > PCN mailing list > >> > > PCN@ietf.org > >> > > https://www1.ietf.org/mailman/listinfo/pcn > >> > > >> > > >> > _______________________________________________ > >> > PCN mailing list > >> > PCN@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 08 06:10:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIiV9-0003Ri-3g; Wed, 08 Aug 2007 06:10:51 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIiV7-0003RX-Tu for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 06:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIiV7-0003RK-Dt for pcn@ietf.org; Wed, 08 Aug 2007 06:10:49 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIiV5-00045H-K6 for pcn@ietf.org; Wed, 08 Aug 2007 06:10:49 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 11:10:44 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Date: Wed, 8 Aug 2007 11:10:43 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC398@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <010001c7d9a0$2859d880$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Thread-Index: AcfZoDw7bFT6CXEHRii45Qu5xB2IJAAAwaMw From: To: , X-OriginalArrivalTime: 08 Aug 2007 10:10:44.0615 (UTC) FILETIME=[620BC170:01C7D9A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: 08 August 2007 10:40 > To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 > Hi Phil, > Sounds excellent:) > A small comment is below. > In this scenario, if Egress does not need to reply any message to Ingress, > it is more reasonable to let the Egress report to the centralized node. > If Egress still needs to replay some message to Ingress, a case which lets > the Ingress report to the Centralized node could be added. [phil] I don't think this is worth doing. there seem to be lots of variants of scenarios with centralised node. I think we've tried in the draft to give a good indication of what they're like but I don't think we need to ensure that we *fully* cover all of them. Because it seems they don't really set new requirements on the marking algorithms, behaviour of the PCN-boundary-nodes, and signalling msgs - rather the mechanism pieces would be put together in slightly different ways=20 > And I could not remember the scenario that the Egress must reply to > Ingress. > If someone remembers, would you remind me? :) [phil] the scenario is when the ingress makes the adm decision (not sure if that's what you were getting at!) phil/ >=20 > B. R. > Tina >=20 > ----- Original Message ----- > From: > To: ; > Sent: Tuesday, August 07, 2007 9:09 PM > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 >=20 > Tina >=20 > delayed follow-up (now I'm editing draft) >=20 > My proposal: I'm going to handle this by simplifying the para so it > reads: > The decision is made at a centralised node, which requires that the > PCN-egress-node signals to the centralised node about the required > "measurements of PCN-traffic", and that the centralised node signals to > the PCN-ingress-node about the decision about admission control. It > would ... >=20 > The reason is that the bullet a few lines earlier says > Make decision about admission - [cut] As well as the PCN measurements, > the decision takes account of policy and application layer requirements. >=20 > Ie we don't need to repeat this again. >=20 > Hopefully ok? >=20 > phil >=20 > > -----Original Message----- > > From: Tina TSOU [mailto:tena@huawei.com] > > Sent: 13 July 2007 10:27 > > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > > Subject: Re: [PCN] Fwd: I-D > ACTION:draft-eardley-pcn-architecture-00.txt > > > > Sorry, forgot to delete "policy and". They should be display as below. > > > > > The decision is made at a centralised node, which requires that > > > the PCN-egress-node signals to the centralised node about "the > > > required measurements of PCN-traffic" (and that the centralised > > > node learns about application layer requirements), and > > > that the centralised node signals to the PCN-ingress-node about > > > the decision about admission control and relative QoS policies. It > > would > > > be possible for > > > the centralised node to be one of the PCN-boundary-nodes, when > > > clearly the signalling would sometimes be replaced by a message > > > internal to the node. > > > > B. R. > > Tina > > > > ----- Original Message ----- > > From: "Tina TSOU" > > To: ; > > Sent: Friday, July 13, 2007 4:39 PM > > Subject: Re: [PCN] Fwd: I-D > ACTION:draft-eardley-pcn-architecture-00.txt > > > > > > > Hi Phil, > > > Thanks:) > > > > > > Wrt to section 5.4, I suggest as below. > > > /*delete "policy and"*/ > > > /*add "and relative QoS policies"*/ > > > The decision is made at a centralised node, which requires that > > > the PCN-egress-node signals to the centralised node about "the > > > required measurements of PCN-traffic" (and that the centralised > > > node learns about policy and application layer requirements), and > > > that the centralised node signals to the PCN-ingress-node about > > > the decision about admission control and relative QoS policies. It > > would > > > be possible for > > > the centralised node to be one of the PCN-boundary-nodes, when > > > clearly the signalling would sometimes be replaced by a message > > > internal to the node. > > > > > > B. R. > > > Tina > > > > > > ----- Original Message ----- > > > From: > > > To: ; > > > Sent: Thursday, July 12, 2007 7:45 PM > > > Subject: RE: [PCN] Fwd: I-D > ACTION:draft-eardley-pcn-architecture-00.txt > > > > > > > > > Tina > > > > > > Thanks > > > > > > Your changes in S1 & S2 seem good to me. > > > > > > You made a comment in S5.4, but didn't suggest a text change. I > think > > > your comment doesn't need any change to S4 (ie it's already covered > > > either in S5.4 [option of centralised node making decision] or > earlier > > > [ingress node doing policing]. is that ok? > > > > > > Thanks > > > Phil/ > > > > > >> -----Original Message----- > > >> From: Tina TSOU [mailto:tena@huawei.com] > > >> Sent: 11 July 2007 04:56 > > >> To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > > >> Subject: Re: [PCN] Fwd: I-D > > > ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > >> Hi Phil, > > >> I made some proposed specific changes with revised mark together > with > > >> comments in the attachment. > > >> Hope it helps:) > > >> > > >> B. R. > > >> Tina > > >> > > >> ----- Original Message ----- > > >> From: > > >> To: ; > > >> Sent: Monday, July 09, 2007 8:16 PM > > >> Subject: RE: [PCN] Fwd: I-D > > > ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > >> > > >> Tina > > >> Thanks > > >> I'm not sure I completely understand your comments, sorry. > > >> > > >> Is the problem that at the moment the draft only describes the Pull > > >> model and not the Push model? Which lines of text need changing? > > >> (somewhere in Section 5.4 or section 7 or somewhere else?) > > >> > > >> Thanks! > > >> phil > > >> > > >> > -----Original Message----- > > >> > From: Tina TSOU [mailto:tena@huawei.com] > > >> > Sent: 02 July 2007 04:38 > > >> > To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > > >> > Subject: Re: [PCN] Fwd: I-D > > >> ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > > >> > Hi all, > > >> > One of the scenarios I am suggesting is below. > > >> > > > >> > Even in Pull mode, application layer QoS request (via RSVP) > should > > > be > > >> also > > >> > sent from ingress to the centralized node, in centralized node > the > > >> policy > > >> > is > > >> > generated, then the decision is made, and then delivers to the > > > Ingress > > >> to > > >> > enforce. I was not saying that the policy is directly generated > in > > > the > > >> > Ingress. Even the rather that Push mode should be also taken into > > >> account. > > >> > > > >> > I.e. we define the centralized node locates in the transport > control > > >> > layer; > > >> > the Ingress and Egress locate in transport layer. For the > > >> implementation > > >> > of > > >> > physical entities, they are service policy server and PCN-enabled > > >> router > > >> > respectively. > > >> > > > >> > The centralized node is policy decision node, it should be based > on > > >> (1) > > >> > Egress measurement result (2) operator's policies (could be > > > configured > > >> in > > >> > the centralized node) (3) QoS request coming from the application > > >> layer > > >> > (PUSH or PULL mode), to make the decision, and decide which flows > > >> should > > >> > be > > >> > admitted or reject, which flows should be stopped temperately or > > >> > downgraded, > > >> > which flows should be done policing. The generated policy should > be > > >> sent > > >> > to > > >> > ingress for enforcement. > > >> > > > >> > Ingress is the policy enforcement point, it based on the policy > > >> delivered > > >> > by > > >> > the centralized node, (1) it allows flow pass or filter flow, (2) > > > for > > >> the > > >> > flows allowed to pass, it makes policing and coloring based on > the > > >> policy. > > >> > > > >> > Referrence: > > >> > QoS "Push" Model: model where the centralised node "pushes" > traffic > > >> > policies > > >> > to the transport functions to enforce its policy decisions. > > >> > NOTE: In this model, the CPE does not itself support native > > >> application > > >> > independent QoS procedures. > > >> > QoS "Pull" Model: model where, upon request from the transport > > >> processing > > >> > functions, the centralised node provides traffic policies to the > > >> transport > > >> > processing functions. The request from the transport processing > > >> functions > > >> > may itself, for example, be triggered by path-coupled requests > > > coming > > >> from > > >> > user equipment and/or transport network elements. > > >> > > > >> > > > >> > B. R. > > >> > Tina > > >> > > > >> > ----- Original Message ----- > > >> > From: > > >> > To: > > >> > Sent: Thursday, June 28, 2007 11:59 PM > > >> > Subject: RE: [PCN] Fwd: I-D > > >> ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > > >> > > > >> > Hi all, > > >> > > > >> > Just a reminder that all comments on this draft would be great. > It > > >> aims > > >> > to describe the PCN architecture, in light of the PCN WG's > Charter & > > >> its > > >> > Milestone of an Info doc on 'Flow Admission and Termination > > >> Architecture > > >> > within a Diffserv Domain' (due Nov 07). > > >> > > > >> > S1 Introduction. > > >> > This is quite short. If desired, it could be boosted with a > general > > >> > explanation of where PCN fits into the picture of QoS and how > it's > > >> > evolved (compare Section 1.1 of > draft-chan-pcn-problem-statement-01) > > >> > > > >> > S2 Terminology > > >> > In the "Editor's note" are 3 alternative terms that some of the > > >> authors > > >> > preferred. > > >> > > > >> > S3 Assumptions and constraints on scope > > >> > These are the 4 things mentioned in the Charter, plus some > > > explanation > > >> > of them. Are they clear? Also we mention some of the ways that a > > >> future > > >> > revised Charter might look at overcoming some of the > > >> > constraints/assumptions; is this sub-section at the right depth? > > >> > > > >> > S4 High-level functional architecture > > >> > We have tried to write this section (and the following ones) so > that > > >> it > > >> > fits all the various proposals there've been for PCN mechanisms. > > > Does > > >> > this make the section too wishy-washy or too hard to understand? > > >> Should > > >> > it include some comparison of the different mechanisms proposed > > >> > (PCN-interior-node marking algorithms & PCN-boundary-node > > > reactions)? > > >> > > > >> > S5 Detailed Functional architecture > > >> > Is this a reasonable description of the extra functionality that > PCN > > >> > requires on various nodes in the PCN-domain? Is it the right way > to > > >> > split up the description? For clarity / help reader's > understanding, > > >> > should there be some specific examples of how functionality might > be > > >> > distributed (eg "if you followed the deployment model in > > >> > draft-briscoe-tsvwg-cl-architecture-04, then this measurement is > > > made > > >> at > > >> > the PCN-egress-node, communicated to the PCN-ingress-nodes which > > > makes > > >> > the admission decision; etc.") > > >> > > > >> > S6 Design goals and challenges > > >> > This briefly describes some open issues, taken from > > >> > briscoe-tsvwg-cl-architecture. Are there other ones that should > be > > >> > mentioned? Is the problem description at the right level of > depth? > > >> > Should we discuss various possible solutions to these problems? > > >> > > > >> > S7 Deployment scenarios > > >> > Briefly describes some deployment scenarios for pcn? is this at > the > > >> > right level of depth? > > >> > > > >> > S8 Operations and Management > > >> > This section was written in response to the Charter saying that > the > > >> > architecture document should include security, manageability and > > >> > operational considerations. The draft addresses this by providing > > > some > > >> > thoughts under the FCAPS headings: OAM of Faults, Configuration, > > >> > Accounting, Performance and Security? Is this the right way of > > >> > structuring it - does it cover the right set of topics? Is the > text > > > at > > >> > the right level? - eg should it also have a detailed set of > > > parameters > > >> > that would be available for configuration? > > >> > > > >> > An overall question is whether the draft should have more > comparison > > >> of > > >> > the options (pros/cons) for various aspects. > > >> > > > >> > I aim to edit another version of the draft before the ietf (but > > > maybe > > >> > not before the deadline as I'm on hols next week). > > >> > > > >> > Thanks! > > >> > Phil/ > > >> > > > >> > > > >> > > -----Original Message----- > > >> > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > >> > > Sent: 22 June 2007 04:38 > > >> > > To: pcn@ietf.org > > >> > > Subject: [PCN] Fwd: I-D > > > ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > > > >> > > Hi all: > > >> > > Please see the attached E-Mail on the posting of the PCN > > >> Architecture > > >> > > draft. > > >> > > On behave of the editor of this draft: Phil, and the co-authors > of > > >> > this > > >> > > draft, > > >> > > we would like to request for reviews and comments of this draft > > > and > > >> > > welcome > > >> > > any comments for improvements. > > >> > > > > >> > > Please send your comments/discussions of this draft on the PCN > > > list. > > >> > > > > >> > > Thank you for your interest and review of this draft! > > >> > > -- Kwok on behave of the co-authors of this draft -- > > >> > > > > >> > > > > >> > > >To: i-d-announce@ietf.org > > >> > > >Cc: > > >> > > >From: Internet-Drafts@ietf.org > > >> > > >Date: Thu, 21 Jun 2007 15:50:02 -0400 > > >> > > >X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > > >> > > >Subject: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > >X-BeenThere: i-d-announce@ietf.org > > >> > > >X-Mailman-Version: 2.1.5 > > >> > > >Reply-To: internet-drafts@ietf.org > > >> > > >List-Id: i-d-announce.ietf.org > > >> > > >List-Unsubscribe: > > >> > , > > >> > > > = > > >> > > >List-Archive: > > >> > > >List-Post: > > >> > > >List-Help: > > >> > > >List-Subscribe: > > >> > , > > >> > > > > > >> > > >X-Spam-Tests: FORGED_RCVD_HELO=3D0.05,MIME_BOUND_NEXTPART=3D0.106, > > >> > > > NO_REAL_NAME=3D0.178,TO_CC_NOT_NORTEL=3D1,URIBL_MANURI=3D4 > > >> > > >X-Spam-Score: 5.3 > > >> > > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on > > >> > > ecarhea1.nortel.com > > >> > > >X-DNSBL-Score: -50 > > >> > > >X-DNSBL-Servers: bl.nortel.com > > >> > > >X-SMTP-HELO: megatron.ietf.org > > >> > > >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org > > >> > > >X-SMTP-RCPT-TO: > > >> > > > > >> > > > >> > > > >>kboyle@nortel.com,bstucker@nortel.com,balles@nortel.com,bharrath@norte > l > > >> > .c > > >> > > > > >> > > > >> > > > > om,babiarz@nortel.com,audet@nortel.com,aceler@nortel.com,simmonds@nortel > > >> > .c > > >> > > > > >> > > > >> > > > > om,huiwc@nortel.com,amuhanna@nortel.com,mchen@nortel.com,khchan@nortel.c > > >> > om > > >> > > >X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145] > > >> > > >X-SMTP-REASON: PASSED > > >> > > >X-SMTP-ID: 1182455563.14011407 > > >> > > >X-OriginalArrivalTime: 21 Jun 2007 19:52:44.0828 (UTC) > > >> > > >FILETIME=3D[BC4965C0:01C7B43D] > > >> > > > > > >> > > >A New Internet-Draft is available from the on-line > > > Internet-Drafts > > >> > > >directories. > > >> > > > > > >> > > > > > >> > > > Title : Pre-Congestion Notification > > > Architecture > > >> > > > Author(s) : P. Eardley, et al. > > >> > > > Filename : > draft-eardley-pcn-architecture-00.txt > > >> > > > Pages : 27 > > >> > > > Date : 2007-6-21 > > >> > > > > > >> > > > The purpose of this document is to describe a general > > >> > architecture > > >> > > > for flow admission and termination based on aggregated > (pre-) > > >> > > > congestion information in order to protect the quality of > > >> service > > >> > of > > >> > > > established inelastic flows within a single DiffServ > domain. > > >> > > > > > >> > > > > > >> > > >A URL for this Internet-Draft is: > > >> > > > > >> > > > >> > > > >>http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00. > t > > >> > xt > > >> > > > > > >> > > >To remove yourself from the I-D Announcement list, send a > message > > >> to > > >> > > >i-d-announce-request@ietf.org with the word unsubscribe in the > > > body > > >> > of > > >> > > >the message. > > >> > > >You can also visit > > >> > https://www1.ietf.org/mailman/listinfo/I-D-announce > > >> > > >to change your subscription settings. > > >> > > > > > >> > > >Internet-Drafts are also available by anonymous FTP. Login > with > > > the > > >> > > >username "anonymous" and a password of your e-mail address. > After > > >> > > >logging in, type "cd internet-drafts" and then > > >> > > >"get draft-eardley-pcn-architecture-00.txt". > > >> > > > > > >> > > >A list of Internet-Drafts directories can be found in > > >> > > >http://www.ietf.org/shadow.html > > >> > > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >> > > > > > >> > > >Internet-Drafts can also be obtained by e-mail. > > >> > > > > > >> > > >Send a message to: > > >> > > > mailserv@ietf.org. > > >> > > >In the body type: > > >> > > > "FILE > > >> > /internet-drafts/draft-eardley-pcn-architecture-00.txt". > > >> > > > > > >> > > >NOTE: The mail server at ietf.org can return the document in > > >> > > > MIME-encoded form by using the "mpack" utility. To > use > > >> this > > >> > > > feature, insert the command "ENCODING mime" before > the > > >> > "FILE" > > >> > > > command. To decode the response(s), you will need > > >> "munpack" > > >> > or > > >> > > > a MIME-compliant mail reader. Different > MIME-compliant > > >> mail > > >> > > readers > > >> > > > exhibit different behavior, especially when dealing > with > > >> > > > "multipart" MIME messages (i.e. documents which have > > > been > > >> > split > > >> > > > up into multiple messages), so check your local > > >> > documentation on > > >> > > > how to manipulate these messages. > > >> > > > > > >> > > >Below is the data which will enable a MIME compliant mail > reader > > >> > > >implementation to automatically retrieve the ASCII version of > the > > >> > > >Internet-Draft. > > >> > > > > > >> > > >Content-Type: text/plain > > >> > > >Content-ID: <2007-6-21120238.I-D@ietf.org> > > >> > > > > > >> > > >ENCODING mime > > >> > > >FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt > > >> > > > > > >> > > > > > >> > > > > >> > >> > > 00.txt> > > >> > > >_______________________________________________ > > >> > > >I-D-Announce mailing list > > >> > > >I-D-Announce@ietf.org > > >> > > >https://www1.ietf.org/mailman/listinfo/i-d-announce > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > _______________________________________________ > > >> > > PCN mailing list > > >> > > PCN@ietf.org > > >> > > https://www1.ietf.org/mailman/listinfo/pcn > > >> > > > >> > > > >> > _______________________________________________ > > >> > PCN mailing list > > >> > PCN@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 08 06:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIiqt-0000to-2j; Wed, 08 Aug 2007 06:33:19 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIiqr-0000tj-2b for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 06:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIiqq-0000tb-Ff for pcn@ietf.org; Wed, 08 Aug 2007 06:33:16 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIiqn-0004ZU-7A for pcn@ietf.org; Wed, 08 Aug 2007 06:33:16 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMG00NABAM60K@szxga03-in.huawei.com> for pcn@ietf.org; Wed, 08 Aug 2007 18:32:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMG00M84AM3GX@szxga03-in.huawei.com> for pcn@ietf.org; Wed, 08 Aug 2007 18:32:30 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMG00NW0AM32T@szxml04-in.huawei.com> for pcn@ietf.org; Wed, 08 Aug 2007 18:32:27 +0800 (CST) Date: Wed, 08 Aug 2007 18:32:26 +0800 From: Tina TSOU Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt To: pcn@ietf.org, philip.eardley@bt.com Message-id: <01a001c7d9a7$6a707830$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC398@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 1.2 (+) X-Scan-Signature: 8897a8f96c648179e32cc9ffbb0aaffd Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, I agree with you:) B. R. Tina ----- Original Message ----- From: To: ; Sent: Wednesday, August 08, 2007 6:10 PM Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: 08 August 2007 10:40 > To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > Subject: Re: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > Hi Phil, > Sounds excellent:) > A small comment is below. > In this scenario, if Egress does not need to reply any message to Ingress, > it is more reasonable to let the Egress report to the centralized node. > If Egress still needs to replay some message to Ingress, a case which lets > the Ingress report to the Centralized node could be added. [phil] I don't think this is worth doing. there seem to be lots of variants of scenarios with centralised node. I think we've tried in the draft to give a good indication of what they're like but I don't think we need to ensure that we *fully* cover all of them. Because it seems they don't really set new requirements on the marking algorithms, behaviour of the PCN-boundary-nodes, and signalling msgs - rather the mechanism pieces would be put together in slightly different ways > And I could not remember the scenario that the Egress must reply to > Ingress. > If someone remembers, would you remind me? :) [phil] the scenario is when the ingress makes the adm decision (not sure if that's what you were getting at!) phil/ > > B. R. > Tina > > ----- Original Message ----- > From: > To: ; > Sent: Tuesday, August 07, 2007 9:09 PM > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > > Tina > > delayed follow-up (now I'm editing draft) > > My proposal: I'm going to handle this by simplifying the para so it > reads: > The decision is made at a centralised node, which requires that the > PCN-egress-node signals to the centralised node about the required > "measurements of PCN-traffic", and that the centralised node signals to > the PCN-ingress-node about the decision about admission control. It > would ... > > The reason is that the bullet a few lines earlier says > Make decision about admission - [cut] As well as the PCN measurements, > the decision takes account of policy and application layer requirements. > > Ie we don't need to repeat this again. > > Hopefully ok? > > phil > > > -----Original Message----- > > From: Tina TSOU [mailto:tena@huawei.com] > > Sent: 13 July 2007 10:27 > > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > > Subject: Re: [PCN] Fwd: I-D > ACTION:draft-eardley-pcn-architecture-00.txt > > > > Sorry, forgot to delete "policy and". They should be display as below. > > > > > The decision is made at a centralised node, which requires that > > > the PCN-egress-node signals to the centralised node about "the > > > required measurements of PCN-traffic" (and that the centralised > > > node learns about application layer requirements), and > > > that the centralised node signals to the PCN-ingress-node about > > > the decision about admission control and relative QoS policies. It > > would > > > be possible for > > > the centralised node to be one of the PCN-boundary-nodes, when > > > clearly the signalling would sometimes be replaced by a message > > > internal to the node. > > > > B. R. > > Tina > > > > ----- Original Message ----- > > From: "Tina TSOU" > > To: ; > > Sent: Friday, July 13, 2007 4:39 PM > > Subject: Re: [PCN] Fwd: I-D > ACTION:draft-eardley-pcn-architecture-00.txt > > > > > > > Hi Phil, > > > Thanks:) > > > > > > Wrt to section 5.4, I suggest as below. > > > /*delete "policy and"*/ > > > /*add "and relative QoS policies"*/ > > > The decision is made at a centralised node, which requires that > > > the PCN-egress-node signals to the centralised node about "the > > > required measurements of PCN-traffic" (and that the centralised > > > node learns about policy and application layer requirements), and > > > that the centralised node signals to the PCN-ingress-node about > > > the decision about admission control and relative QoS policies. It > > would > > > be possible for > > > the centralised node to be one of the PCN-boundary-nodes, when > > > clearly the signalling would sometimes be replaced by a message > > > internal to the node. > > > > > > B. R. > > > Tina > > > > > > ----- Original Message ----- > > > From: > > > To: ; > > > Sent: Thursday, July 12, 2007 7:45 PM > > > Subject: RE: [PCN] Fwd: I-D > ACTION:draft-eardley-pcn-architecture-00.txt > > > > > > > > > Tina > > > > > > Thanks > > > > > > Your changes in S1 & S2 seem good to me. > > > > > > You made a comment in S5.4, but didn't suggest a text change. I > think > > > your comment doesn't need any change to S4 (ie it's already covered > > > either in S5.4 [option of centralised node making decision] or > earlier > > > [ingress node doing policing]. is that ok? > > > > > > Thanks > > > Phil/ > > > > > >> -----Original Message----- > > >> From: Tina TSOU [mailto:tena@huawei.com] > > >> Sent: 11 July 2007 04:56 > > >> To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > > >> Subject: Re: [PCN] Fwd: I-D > > > ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > >> Hi Phil, > > >> I made some proposed specific changes with revised mark together > with > > >> comments in the attachment. > > >> Hope it helps:) > > >> > > >> B. R. > > >> Tina > > >> > > >> ----- Original Message ----- > > >> From: > > >> To: ; > > >> Sent: Monday, July 09, 2007 8:16 PM > > >> Subject: RE: [PCN] Fwd: I-D > > > ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > >> > > >> Tina > > >> Thanks > > >> I'm not sure I completely understand your comments, sorry. > > >> > > >> Is the problem that at the moment the draft only describes the Pull > > >> model and not the Push model? Which lines of text need changing? > > >> (somewhere in Section 5.4 or section 7 or somewhere else?) > > >> > > >> Thanks! > > >> phil > > >> > > >> > -----Original Message----- > > >> > From: Tina TSOU [mailto:tena@huawei.com] > > >> > Sent: 02 July 2007 04:38 > > >> > To: pcn@ietf.org; Eardley,PL,Philip,CXR9 R > > >> > Subject: Re: [PCN] Fwd: I-D > > >> ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > > >> > Hi all, > > >> > One of the scenarios I am suggesting is below. > > >> > > > >> > Even in Pull mode, application layer QoS request (via RSVP) > should > > > be > > >> also > > >> > sent from ingress to the centralized node, in centralized node > the > > >> policy > > >> > is > > >> > generated, then the decision is made, and then delivers to the > > > Ingress > > >> to > > >> > enforce. I was not saying that the policy is directly generated > in > > > the > > >> > Ingress. Even the rather that Push mode should be also taken into > > >> account. > > >> > > > >> > I.e. we define the centralized node locates in the transport > control > > >> > layer; > > >> > the Ingress and Egress locate in transport layer. For the > > >> implementation > > >> > of > > >> > physical entities, they are service policy server and PCN-enabled > > >> router > > >> > respectively. > > >> > > > >> > The centralized node is policy decision node, it should be based > on > > >> (1) > > >> > Egress measurement result (2) operator's policies (could be > > > configured > > >> in > > >> > the centralized node) (3) QoS request coming from the application > > >> layer > > >> > (PUSH or PULL mode), to make the decision, and decide which flows > > >> should > > >> > be > > >> > admitted or reject, which flows should be stopped temperately or > > >> > downgraded, > > >> > which flows should be done policing. The generated policy should > be > > >> sent > > >> > to > > >> > ingress for enforcement. > > >> > > > >> > Ingress is the policy enforcement point, it based on the policy > > >> delivered > > >> > by > > >> > the centralized node, (1) it allows flow pass or filter flow, (2) > > > for > > >> the > > >> > flows allowed to pass, it makes policing and coloring based on > the > > >> policy. > > >> > > > >> > Referrence: > > >> > QoS "Push" Model: model where the centralised node "pushes" > traffic > > >> > policies > > >> > to the transport functions to enforce its policy decisions. > > >> > NOTE: In this model, the CPE does not itself support native > > >> application > > >> > independent QoS procedures. > > >> > QoS "Pull" Model: model where, upon request from the transport > > >> processing > > >> > functions, the centralised node provides traffic policies to the > > >> transport > > >> > processing functions. The request from the transport processing > > >> functions > > >> > may itself, for example, be triggered by path-coupled requests > > > coming > > >> from > > >> > user equipment and/or transport network elements. > > >> > > > >> > > > >> > B. R. > > >> > Tina > > >> > > > >> > ----- Original Message ----- > > >> > From: > > >> > To: > > >> > Sent: Thursday, June 28, 2007 11:59 PM > > >> > Subject: RE: [PCN] Fwd: I-D > > >> ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > > >> > > > >> > Hi all, > > >> > > > >> > Just a reminder that all comments on this draft would be great. > It > > >> aims > > >> > to describe the PCN architecture, in light of the PCN WG's > Charter & > > >> its > > >> > Milestone of an Info doc on 'Flow Admission and Termination > > >> Architecture > > >> > within a Diffserv Domain' (due Nov 07). > > >> > > > >> > S1 Introduction. > > >> > This is quite short. If desired, it could be boosted with a > general > > >> > explanation of where PCN fits into the picture of QoS and how > it's > > >> > evolved (compare Section 1.1 of > draft-chan-pcn-problem-statement-01) > > >> > > > >> > S2 Terminology > > >> > In the "Editor's note" are 3 alternative terms that some of the > > >> authors > > >> > preferred. > > >> > > > >> > S3 Assumptions and constraints on scope > > >> > These are the 4 things mentioned in the Charter, plus some > > > explanation > > >> > of them. Are they clear? Also we mention some of the ways that a > > >> future > > >> > revised Charter might look at overcoming some of the > > >> > constraints/assumptions; is this sub-section at the right depth? > > >> > > > >> > S4 High-level functional architecture > > >> > We have tried to write this section (and the following ones) so > that > > >> it > > >> > fits all the various proposals there've been for PCN mechanisms. > > > Does > > >> > this make the section too wishy-washy or too hard to understand? > > >> Should > > >> > it include some comparison of the different mechanisms proposed > > >> > (PCN-interior-node marking algorithms & PCN-boundary-node > > > reactions)? > > >> > > > >> > S5 Detailed Functional architecture > > >> > Is this a reasonable description of the extra functionality that > PCN > > >> > requires on various nodes in the PCN-domain? Is it the right way > to > > >> > split up the description? For clarity / help reader's > understanding, > > >> > should there be some specific examples of how functionality might > be > > >> > distributed (eg "if you followed the deployment model in > > >> > draft-briscoe-tsvwg-cl-architecture-04, then this measurement is > > > made > > >> at > > >> > the PCN-egress-node, communicated to the PCN-ingress-nodes which > > > makes > > >> > the admission decision; etc.") > > >> > > > >> > S6 Design goals and challenges > > >> > This briefly describes some open issues, taken from > > >> > briscoe-tsvwg-cl-architecture. Are there other ones that should > be > > >> > mentioned? Is the problem description at the right level of > depth? > > >> > Should we discuss various possible solutions to these problems? > > >> > > > >> > S7 Deployment scenarios > > >> > Briefly describes some deployment scenarios for pcn? is this at > the > > >> > right level of depth? > > >> > > > >> > S8 Operations and Management > > >> > This section was written in response to the Charter saying that > the > > >> > architecture document should include security, manageability and > > >> > operational considerations. The draft addresses this by providing > > > some > > >> > thoughts under the FCAPS headings: OAM of Faults, Configuration, > > >> > Accounting, Performance and Security? Is this the right way of > > >> > structuring it - does it cover the right set of topics? Is the > text > > > at > > >> > the right level? - eg should it also have a detailed set of > > > parameters > > >> > that would be available for configuration? > > >> > > > >> > An overall question is whether the draft should have more > comparison > > >> of > > >> > the options (pros/cons) for various aspects. > > >> > > > >> > I aim to edit another version of the draft before the ietf (but > > > maybe > > >> > not before the deadline as I'm on hols next week). > > >> > > > >> > Thanks! > > >> > Phil/ > > >> > > > >> > > > >> > > -----Original Message----- > > >> > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > >> > > Sent: 22 June 2007 04:38 > > >> > > To: pcn@ietf.org > > >> > > Subject: [PCN] Fwd: I-D > > > ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > > > >> > > Hi all: > > >> > > Please see the attached E-Mail on the posting of the PCN > > >> Architecture > > >> > > draft. > > >> > > On behave of the editor of this draft: Phil, and the co-authors > of > > >> > this > > >> > > draft, > > >> > > we would like to request for reviews and comments of this draft > > > and > > >> > > welcome > > >> > > any comments for improvements. > > >> > > > > >> > > Please send your comments/discussions of this draft on the PCN > > > list. > > >> > > > > >> > > Thank you for your interest and review of this draft! > > >> > > -- Kwok on behave of the co-authors of this draft -- > > >> > > > > >> > > > > >> > > >To: i-d-announce@ietf.org > > >> > > >Cc: > > >> > > >From: Internet-Drafts@ietf.org > > >> > > >Date: Thu, 21 Jun 2007 15:50:02 -0400 > > >> > > >X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > > >> > > >Subject: I-D ACTION:draft-eardley-pcn-architecture-00.txt > > >> > > >X-BeenThere: i-d-announce@ietf.org > > >> > > >X-Mailman-Version: 2.1.5 > > >> > > >Reply-To: internet-drafts@ietf.org > > >> > > >List-Id: i-d-announce.ietf.org > > >> > > >List-Unsubscribe: > > >> > , > > >> > > > > > >> > > >List-Archive: > > >> > > >List-Post: > > >> > > >List-Help: > > >> > > >List-Subscribe: > > >> > , > > >> > > > > > >> > > >X-Spam-Tests: FORGED_RCVD_HELO=0.05,MIME_BOUND_NEXTPART=0.106, > > >> > > > NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1,URIBL_MANURI=4 > > >> > > >X-Spam-Score: 5.3 > > >> > > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on > > >> > > ecarhea1.nortel.com > > >> > > >X-DNSBL-Score: -50 > > >> > > >X-DNSBL-Servers: bl.nortel.com > > >> > > >X-SMTP-HELO: megatron.ietf.org > > >> > > >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org > > >> > > >X-SMTP-RCPT-TO: > > >> > > > > >> > > > >> > > > >>kboyle@nortel.com,bstucker@nortel.com,balles@nortel.com,bharrath@norte > l > > >> > .c > > >> > > > > >> > > > >> > > > > om,babiarz@nortel.com,audet@nortel.com,aceler@nortel.com,simmonds@nortel > > >> > .c > > >> > > > > >> > > > >> > > > > om,huiwc@nortel.com,amuhanna@nortel.com,mchen@nortel.com,khchan@nortel.c > > >> > om > > >> > > >X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145] > > >> > > >X-SMTP-REASON: PASSED > > >> > > >X-SMTP-ID: 1182455563.14011407 > > >> > > >X-OriginalArrivalTime: 21 Jun 2007 19:52:44.0828 (UTC) > > >> > > >FILETIME=[BC4965C0:01C7B43D] > > >> > > > > > >> > > >A New Internet-Draft is available from the on-line > > > Internet-Drafts > > >> > > >directories. > > >> > > > > > >> > > > > > >> > > > Title : Pre-Congestion Notification > > > Architecture > > >> > > > Author(s) : P. Eardley, et al. > > >> > > > Filename : > draft-eardley-pcn-architecture-00.txt > > >> > > > Pages : 27 > > >> > > > Date : 2007-6-21 > > >> > > > > > >> > > > The purpose of this document is to describe a general > > >> > architecture > > >> > > > for flow admission and termination based on aggregated > (pre-) > > >> > > > congestion information in order to protect the quality of > > >> service > > >> > of > > >> > > > established inelastic flows within a single DiffServ > domain. > > >> > > > > > >> > > > > > >> > > >A URL for this Internet-Draft is: > > >> > > > > >> > > > >> > > > >>http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00. > t > > >> > xt > > >> > > > > > >> > > >To remove yourself from the I-D Announcement list, send a > message > > >> to > > >> > > >i-d-announce-request@ietf.org with the word unsubscribe in the > > > body > > >> > of > > >> > > >the message. > > >> > > >You can also visit > > >> > https://www1.ietf.org/mailman/listinfo/I-D-announce > > >> > > >to change your subscription settings. > > >> > > > > > >> > > >Internet-Drafts are also available by anonymous FTP. Login > with > > > the > > >> > > >username "anonymous" and a password of your e-mail address. > After > > >> > > >logging in, type "cd internet-drafts" and then > > >> > > >"get draft-eardley-pcn-architecture-00.txt". > > >> > > > > > >> > > >A list of Internet-Drafts directories can be found in > > >> > > >http://www.ietf.org/shadow.html > > >> > > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >> > > > > > >> > > >Internet-Drafts can also be obtained by e-mail. > > >> > > > > > >> > > >Send a message to: > > >> > > > mailserv@ietf.org. > > >> > > >In the body type: > > >> > > > "FILE > > >> > /internet-drafts/draft-eardley-pcn-architecture-00.txt". > > >> > > > > > >> > > >NOTE: The mail server at ietf.org can return the document in > > >> > > > MIME-encoded form by using the "mpack" utility. To > use > > >> this > > >> > > > feature, insert the command "ENCODING mime" before > the > > >> > "FILE" > > >> > > > command. To decode the response(s), you will need > > >> "munpack" > > >> > or > > >> > > > a MIME-compliant mail reader. Different > MIME-compliant > > >> mail > > >> > > readers > > >> > > > exhibit different behavior, especially when dealing > with > > >> > > > "multipart" MIME messages (i.e. documents which have > > > been > > >> > split > > >> > > > up into multiple messages), so check your local > > >> > documentation on > > >> > > > how to manipulate these messages. > > >> > > > > > >> > > >Below is the data which will enable a MIME compliant mail > reader > > >> > > >implementation to automatically retrieve the ASCII version of > the > > >> > > >Internet-Draft. > > >> > > > > > >> > > >Content-Type: text/plain > > >> > > >Content-ID: <2007-6-21120238.I-D@ietf.org> > > >> > > > > > >> > > >ENCODING mime > > >> > > >FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt > > >> > > > > > >> > > > > > >> > > > > >> > >> > > 00.txt> > > >> > > >_______________________________________________ > > >> > > >I-D-Announce mailing list > > >> > > >I-D-Announce@ietf.org > > >> > > >https://www1.ietf.org/mailman/listinfo/i-d-announce > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > _______________________________________________ > > >> > > PCN mailing list > > >> > > PCN@ietf.org > > >> > > https://www1.ietf.org/mailman/listinfo/pcn > > >> > > > >> > > > >> > _______________________________________________ > > >> > PCN mailing list > > >> > PCN@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 08 10:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIn0e-0003OT-Vr; Wed, 08 Aug 2007 10:59:40 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIn0e-0003OO-Lp for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 10:59:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIn0e-0003OG-AW for pcn@ietf.org; Wed, 08 Aug 2007 10:59:40 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIn0d-0001OG-Sd for pcn@ietf.org; Wed, 08 Aug 2007 10:59:40 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 15:54:28 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] O+M section Date: Wed, 8 Aug 2007 15:53:07 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC39B@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <01b901c7ced0$91743520$4fa81cac@jys3105121962> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] O+M section Thread-Index: AcfO0JYZGhS92FjEQuOEvrJQiSJ0YwK8x2hQ From: To: , X-OriginalArrivalTime: 08 Aug 2007 14:54:28.0931 (UTC) FILETIME=[05543930:01C7D9CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0472797879==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0472797879== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D9CB.D4CD570D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D9CB.D4CD570D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tina, Tom, Bob, all, =20 Thanks for this. =20 A general comment - quite a lot of your changes to the section are to add lists of parameters to be collected /configured etc at PCN-nodes. Personally this seems a bit inappropriate to me for an architecture doc - too detailed - better in a MIB?? (Incidentally I disagree with some of the parameters.)=20 =20 I'll try and work in most of your other suggestions, whilst also reading bob's input in parallel, which also says most of what I wrote is rubbish. =3D> the OAM section will shrink in this version as I'll delete most of what I wrote. =20 However, the good news is that Bob has offered to provide a whole new OAM section (but not today, as he's currently enjoying the new improved bt Expenses system!! - so it won't make this version). Maybe Tom and any other keen OAMers can liaise with bob on this.=20 =20 Thanks! phil =20 =20 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: 25 July 2007 16:29 To: pcn@ietf.org Subject: [PCN] O+M section =20 Hi all, As promised, attached please find the O+M section which was discussed in the arch designing team. Hope it can be a basis or starting point as the O+M part in the ML. =20 B. R. Tina Messengers:=20 MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com ------_=_NextPart_001_01C7D9CB.D4CD570D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tina, Tom, Bob, = all,

 

Thanks for this.

 

A general comment - quite a lot of = your changes to the section are to add lists of parameters to be collected = /configured etc at PCN-nodes. Personally this seems a bit inappropriate to me for an architecture doc - too detailed – better in a MIB??  = (Incidentally I disagree with some of the parameters.)

 

I’ll try and work in most of = your other suggestions, whilst also reading bob’s input in parallel, = which also says most of what I wrote is rubbish.

=3D> the OAM section will shrink = in this version as I’ll delete most of what I wrote.

 

However, the good news is that Bob = has offered to provide a whole new OAM section (but not today, as he’s currently enjoying the new improved bt Expenses system!! - so it = won’t make this version). Maybe Tom and any other keen OAMers can liaise with = bob on this.

 

Thanks!

phil

 

 

-----Original Message-----
From: Tina TSOU [mailto:tena@huawei.com]
Sent: 25 July 2007 = 16:29
To: pcn@ietf.org
Subject: [PCN] O+M = section

 

Hi all,

As promised, attached please find the O+M section = which was discussed in the arch designing team.

Hope it can be a basis or starting point as the O+M = part in the ML.

 

B. R.
Tina
Messengers:
MSN: tinatsou6@hotmail.com &nbs= p; Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber: tina@jabber.org    = Google talk: tinatsou6@gmail.com=

=00 ------_=_NextPart_001_01C7D9CB.D4CD570D-- --===============0472797879== 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://www1.ietf.org/mailman/listinfo/pcn --===============0472797879==-- From pcn-bounces@ietf.org Wed Aug 08 13:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIpTA-0007gU-T1; Wed, 08 Aug 2007 13:37:16 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIpTA-0007gP-GS for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 13:37:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIpTA-0007gH-6H for pcn@ietf.org; Wed, 08 Aug 2007 13:37:16 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIpT8-0006jY-7r for pcn@ietf.org; Wed, 08 Aug 2007 13:37:16 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 18:37:13 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Aug 2007 18:37:13 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A0@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN architecture, use of phrases like "exceeds rate" Thread-Index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDA== From: To: X-OriginalArrivalTime: 08 Aug 2007 17:37:13.0250 (UTC) FILETIME=[C1511020:01C7D9E2] X-Spam-Score: -1.0 (-) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b Subject: [PCN] PCN architecture, use of phrases like "exceeds rate" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0905290202==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0905290202== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D9E2.C16BDFCD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D9E2.C16BDFCD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wrote a new / replacement para in the intro - to try to overcome bob's rant - which complained about using phrases like "do marking when the current rate exceeds a reference rate" [copied at end] - whilst still giving the innocent reader (if such a person exists) a sporting chance of understanding what it's all about: =20 <> =20 I know the last bit mentions rate - hopefully it's ok by relating it to the overall system performance, rather than how each link does marking. I'm not sure whether "*roughly*" is really necessary or whether you think i cheated.=20 =20 I also added to the definitions for example: <> =20 ** bob's rant > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. =20 =20 =20 ------_=_NextPart_001_01C7D9E2.C16BDFCD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wrote a new / replacement para in the intro - to try to = overcome bob’s rant - which complained about using phrases like “do marking when = the current rate exceeds a reference rate” [copied at end] - whilst = still giving the innocent reader (if such a person exists) a sporting chance = of understanding what it's all about:

 

<<Two rates, a PCN-lower-rate and a PCN-upper-rate, can be associated with each link of the PCN-domain. Each rate is used by an = algorithm (specified in another document) that determines how and when a number of PCN-packets are marked, and how the markings are encoded in packet = headers. PCN-egress-nodes make measurements of the packet markings and send = information as necessary to the nodes that make the decision about which PCN-flows = to accept/reject or terminate, based on this information. Another document = will describe decision-making algorithms. Overall the aim is to enable = PCN-nodes to give an "early warning" of potential congestion before there = is any significant build-up of PCN-packets in the queue; the admission control = mechanism limits the PCN-traffic on each link to *roughly* its PCN-lower-rate and = the flow termination mechanism limits the PCN-traffic on each link to = *roughly* its PCN-upper-rate.>>

 

I know the last bit mentions rate - hopefully it's ok by = relating it to the overall system performance, rather than how each link does marking. = I'm not sure whether "*roughly*" is really necessary or whether you = think i cheated.

 

I also added to the definitions for example:

<<Threshold-marking: a PCN-marking algorithm such that all PCN-traffic is marked if the PCN-traffic exceeds a particular rate = (either the PCN-lower-rate or PCN-upper-rate). NOTE: The definition reflects the = overall intent of the algorithm rather than its instantaneous behaviour, since = the rate measured at a particular moment depends on the algorithm, its = implementation and the traffic's variance as well as its = rate.>>

 

** bob’s rant

> * Marking is when "current" rate is = "above" a reference rate?

>

> "   o  Admission-marking: the marking = of PCN-packets by a PCN-node to

>        indicate that the = PCN-traffic on a link is above the configured-

>        = admissible-rate.

>

>     o  Termination-marking: the = marking of PCN-packets by a PCN-node to

>        indicate that the = PCN-traffic on a link is above the configured-

>        = termination-rate.

> "

>

> These marking definitions and other examples hilighted in = magenta in the

> above PDF prejudge marking mechanisms as rate = measurements.

>

> We don't just have marking when the _current_rate is = _above_ the reference

> rate. We can have marking when the _current_ rate is = _below_, or when the

> _past_ rate was _above_.

>

> The configured rates are parameters of a (to be defined) mechanism. These

> mechanisms will not have to mark packets when the rate is = above these

> configured rates. That depends on the = mechanism.

>

> This sounds picky, but it's actually a big rant I have = about all this

> loose

> discussion of rate (yes, the issue of what rate means is = mentioned in the

> draft, but we need to be careful about such sloppy usage). = IMHO, it's

> important to scale our conception of time down to = inter-arrival times, to

> be precise. Then the rate is packet size/interarrival time. Therefore seen

> at a small enough timescale, rate might be varying rapidly = above and below

> the configured rate.

>

> A marking mechanism could be implemented by a virtual queue = rather than a

> rate measurement. When the offered instantaneous rate has = been below the

> configured-admission-rate for many packets (perhaps = hundreds), marking

> will

> and should still occur,... if the virtual queue is still = above a marking

> threshold even if it is emptying rather than filling. This = can be a

> deliberate design choice that says we still want admission = marking when

> there has been recent overload to allow time for the = control loop to work.

> It ensures a greater safety margin is automatically created = by the marking

> mechanism when recent traffic had higher variance. This was = the marking

> algorithm that was most studied and simulated in CL-PHB = draft.

 

 

 

=00 ------_=_NextPart_001_01C7D9E2.C16BDFCD-- --===============0905290202== 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://www1.ietf.org/mailman/listinfo/pcn --===============0905290202==-- From pcn-bounces@ietf.org Wed Aug 08 18:07:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItgG-0005zM-Vf; Wed, 08 Aug 2007 18:07:04 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IItgG-0005zH-17 for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItgF-0005z9-LM for pcn@ietf.org; Wed, 08 Aug 2007 18:07:03 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IItgC-0003t5-UB for pcn@ietf.org; Wed, 08 Aug 2007 18:07:03 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 23:06:42 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7DA08.7149792D" Date: Wed, 8 Aug 2007 23:06:59 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: new version of PCN architecture draft Thread-Index: AcfaCHEWddGszs9VRr6hcymHsWXxmg== From: To: X-OriginalArrivalTime: 08 Aug 2007 22:06:42.0518 (UTC) FILETIME=[66F38F60:01C7DA08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a6d29e05c990cc4882f6dc55138549e Subject: [PCN] new version of PCN architecture draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DA08.7149792D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7DA08.7149792D" ------_=_NextPart_002_01C7DA08.7149792D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable here it is! (attached whilst it gets posted). =20 Btw I had some trouble with references, the files at=20 http://xml.resource.org/public/rfc/bibxml3/ seem to be out of date [updated april?]. the ones I didn't find there are a bit minimal, due to negative typing time, but hopefully clear. I haven't i-d nitted it. =20 I also started [or will start in next few mins] mail threads on some changes that I think need flagging up to people and probably discussion. changes I've done as a result of people's comments and suggestions. Sorry this results in a few emails, I hope your spam filters cope, but i thought this was better than wrapping everything into one email.=20 =20 Thanks for your reviews and comments! =20 Best wishes Phil Eardley=20 =20 =20 ------_=_NextPart_002_01C7DA08.7149792D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

here it is! (attached whilst it gets = posted).

 

Btw I had some trouble with references, the = files at http://xml.resource.= org/public/rfc/bibxml3/ seem to be out of date [updated april?]. the ones I didn’t find = there are a bit minimal, due to negative typing time, but hopefully clear. I = haven’t i-d nitted it.

 

I also started [or will start in next few mins] mail threads on = some changes that I think need flagging up to people and probably discussion. changes = I've done as a result of people's comments and suggestions. Sorry this = results in a few emails, I hope your spam filters cope, but i thought this was better = than wrapping everything into one email.

 

Thanks for your reviews and = comments!

 

Best wishes

Phil Eardley

 

 

=00 ------_=_NextPart_002_01C7DA08.7149792D-- ------_=_NextPart_001_01C7DA08.7149792D Content-Type: text/plain; name="draft-ietf-pcn-architecture-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-pcn-architecture-00.txt Content-Disposition: attachment; filename="draft-ietf-pcn-architecture-00.txt" DQoNCg0KQ29uZ2VzdGlvbiBhbmQgUHJlLUNvbmdlc3Rpb24gICAgICAgICAgICAgICAgICAgUGhp bGlwLiBFYXJkbGV5IChFZGl0b3IpDQpOb3RpZmljYXRpb24gV29ya2luZyBHcm91cCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQlQNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgOCwgMjAwNw0K SW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsDQpFeHBpcmVzOiBGZWJydWFyeSA5LCAyMDA4 DQoNCg0KICAgICAgICAgICAgICAgIFByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiBBcmNoaXRl Y3R1cmUNCiAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtcGNuLWFyY2hpdGVjdHVyZS0w MA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5l dC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBw YXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAg IGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBz aGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0 aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVU RiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3Ro ZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRp bWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJl bmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMu dHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg Y2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0K DQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEZlYnJ1YXJ5IDksIDIwMDgu DQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAo MjAwNykuDQoNCkFic3RyYWN0DQoNCiAgIFRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMg dG8gZGVzY3JpYmUgYSBnZW5lcmFsIGFyY2hpdGVjdHVyZQ0KICAgZm9yIGZsb3cgYWRtaXNzaW9u IGFuZCB0ZXJtaW5hdGlvbiBiYXNlZCBvbiBhZ2dyZWdhdGVkIHByZS1jb25nZXN0aW9uDQogICBp bmZvcm1hdGlvbiBpbiBvcmRlciB0byBwcm90ZWN0IHRoZSBxdWFsaXR5IG9mIHNlcnZpY2Ugb2Yg ZXN0YWJsaXNoZWQNCiAgIGluZWxhc3RpYyBmbG93cyB3aXRoaW4gYSBzaW5nbGUgRGlmZlNlcnYg ZG9tYWluLg0KDQoNCg0KDQoNCg0KRWFyZGxleSAoRWRpdG9yKSAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSA5LCAyMDA4ICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgIERvY3VtZW50ICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcN Cg0KDQpTdGF0dXMNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAg IDIuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNg0KICAgMy4gIEFzc3VtcHRpb25zIGFuZCBjb25zdHJhaW50cyBvbiBzY29w ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgIDMuMS4gIEFzc3VtcHRpb24gMTog VHJ1c3QgLSBjb250cm9sbGVkIGVudmlyb25tZW50IC4gLiAuIC4gLiAuIC4gIDgNCiAgICAgMy4y LiAgQXNzdW1wdGlvbiAyOiBSZWFsLXRpbWUgYXBwbGljYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgOQ0KICAgICAzLjMuICBBc3N1bXB0aW9uIDM6IE1hbnkgZmxvd3MgYW5kIGFkZGl0aW9u YWwgbG9hZCAuIC4gLiAuIC4gLiAuICA5DQogICAgIDMuNC4gIEFzc3VtcHRpb24gNDogRW1lcmdl bmN5IHVzZSBvdXQgb2Ygc2NvcGUgLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgMy41LiAgT3Ro ZXIgYXNzdW1wdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx MA0KICAgNC4gIEhpZ2gtbGV2ZWwgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEwDQogICA1LiAgRGV0YWlsZWQgRnVuY3Rpb25hbCBhcmNoaXRlY3R1 cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgICAgNS4xLiAgUENOLWludGVy aW9yLW5vZGUgZnVuY3Rpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAg ICA1LjIuICBQQ04taW5ncmVzcy1ub2RlIGZ1bmN0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE1DQogICAgIDUuMy4gIFBDTi1lZ3Jlc3Mtbm9kZSBmdW5jdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgNS40LiAgQWRtaXNzaW9uIGNvbnRy b2wgZnVuY3Rpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgICA1LjUu ICBQcm9iaW5nIGZ1bmN0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE3DQogICAgIDUuNi4gIEZsb3cgdGVybWluYXRpb24gZnVuY3Rpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgICAgNS43LiAgQWRkcmVzc2luZyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0KICAgICA1LjguICBUdW5u ZWxsaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5 DQogICAgIDUuOS4gIEZhdWx0IGhhbmRsaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjANCiAgIDYuICBEZXNpZ24gZ29hbHMgYW5kIGNoYWxsZW5nZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQ0KICAgNy4gIE9wZXJhdGlvbnMgYW5k IE1hbmFnZW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzDQogICAg IDcuMS4gIEZhdWx0IE9BTSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjMNCiAgICAgNy4yLiAgQ29uZmlndXJhdGlvbiBPQU0gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMw0KICAgICA3LjMuICBBY2NvdW50aW5nIE9BTSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICAgIDcuNC4g IFBlcmZvcm1hbmNlIE9BTSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjUNCiAgICAgNy41LiAgU2VjdXJpdHkgT0FNIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyNg0KICAgOC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQogICA5LiAgU2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjYN CiAgIDEwLiBDb25jbHVzaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyNw0KICAgMTEuIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3DQogICAxMi4gQ29tbWVudHMgU29saWNp dGVkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgIDEz LiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyOA0KICAgICAxMy4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4DQogICAgIDEzLjIuIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgIEF1dGhvcidz IEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzMQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAu IC4gLiAuIC4gLiAuIC4gLiAuIDMyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkVhcmRsZXkgKEVkaXRv cikgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBUaGUgcHVy cG9zZSBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGRlc2NyaWJlIGEgZ2VuZXJhbCBhcmNoaXRlY3R1 cmUNCiAgIGZvciBmbG93IGFkbWlzc2lvbiBhbmQgdGVybWluYXRpb24gYmFzZWQgb24gYWdncmVn YXRlZCAocHJlLSkNCiAgIGNvbmdlc3Rpb24gaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gcHJvdGVj dCB0aGUgcXVhbGl0eSBvZiBzZXJ2aWNlIG9mDQogICBmbG93cyB3aXRoaW4gYSBEaWZmU2VydiBk b21haW4sW1JGQzI0NzVdLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuDQogICBhcmNoaXRlY3R1 cmUgZm9yIGltcGxlbWVudGluZyB0d28gbWVjaGFuaXNtcyB0byBwcm90ZWN0IHRoZSBxdWFsaXR5 DQogICBvZiBzZXJ2aWNlIG9mIGVzdGFibGlzaGVkIGluZWxhc3RpYyBmbG93cyB3aXRoaW4gYSBz aW5nbGUgRGlmZlNlcnYNCiAgIGRvbWFpbiwgd2hlcmUgYWxsIGJvdW5kYXJ5IGFuZCBpbnRlcmlv ciBub2RlcyBhcmUgUENOLWVuYWJsZWQgYW5kDQogICB0cnVzdCBlYWNoIG90aGVyIGZvciBjb3Jy ZWN0IFBDTiBvcGVyYXRpb24uICBGbG93IGFkbWlzc2lvbiBjb250cm9sDQogICBkZXRlcm1pbmVz IHdoZXRoZXIgYSBuZXcgZmxvdyBzaG91bGQgYmUgYWRtaXR0ZWQgYW5kIHByb3RlY3RzIHRoZSBR b1MNCiAgIG9mIGV4aXN0aW5nIFBDTi1mbG93cyBpbiBub3JtYWwgY2lyY3Vtc3RhbmNlcywgYnkg YXZvaWRpbmcgY29uZ2VzdGlvbg0KICAgb2NjdXJyaW5nLiAgSG93ZXZlciwgaW4gYWJub3JtYWwg Y2lyY3Vtc3RhbmNlcywgZm9yIGluc3RhbmNlIGENCiAgIGRpc2FzdGVyIGFmZmVjdGluZyBtdWx0 aXBsZSBub2RlcyBhbmQgY2F1c2luZyB0cmFmZmljIHJlLXJvdXRlcywgdGhlbg0KICAgdGhlIFFv UyBvbiBleGlzdGluZyBQQ04tZmxvd3MgbWF5IGRlZ3JhZGUgZXZlbiB0aG91Z2ggY2FyZSB3YXMN CiAgIGV4ZXJjaXNlZCB3aGVuIGFkbWl0dGluZyB0aG9zZSBmbG93cyBiZWZvcmUgdGhvc2UgY2ly Y3Vtc3RhbmNlcy4NCiAgIFRoZXJlZm9yZSB3ZSBhbHNvIHByb3Bvc2UgYSBtZWNoYW5pc20gZm9y IGZsb3cgdGVybWluYXRpb24sIHdoaWNoDQogICByZW1vdmVzIGVub3VnaCB0cmFmZmljIGluIG9y ZGVyIHRvIHByb3RlY3QgdGhlIFFvUyBvZiB0aGUgcmVtYWluaW5nDQogICBQQ04tZmxvd3MuICBB cyBhIGZ1bmRhbWVudGFsIGJ1aWxkaW5nIGJsb2NrIHRvIGVuYWJsZSB0aGVzZSB0d28NCiAgIG1l Y2hhbmlzbXMsIFBDTi1pbnRlcmlvci1ub2RlcyBnZW5lcmF0ZSwgZW5jb2RlIGFuZCB0cmFuc3Bv cnQgcHJlLQ0KICAgY29uZ2VzdGlvbiBpbmZvcm1hdGlvbiB0b3dhcmRzIHRoZSBQQ04tZWdyZXNz LW5vZGVzLg0KDQogICBUd28gcmF0ZXMsIGEgUENOLWxvd2VyLXJhdGUgYW5kIGEgUENOLXVwcGVy LXJhdGUsIGNhbiBiZSBhc3NvY2lhdGVkDQogICB3aXRoIGVhY2ggbGluayBvZiB0aGUgUENOLWRv bWFpbi4gIEVhY2ggcmF0ZSBpcyB1c2VkIGJ5IGFuIGFsZ29yaXRobQ0KICAgKHNwZWNpZmllZCBp biBhbm90aGVyIGRvY3VtZW50KSB0aGF0IGRldGVybWluZXMgaG93IGFuZCB3aGVuIGEgbnVtYmVy DQogICBvZiBQQ04tcGFja2V0cyBhcmUgbWFya2VkLCBhbmQgaG93IHRoZSBtYXJraW5ncyBhcmUg ZW5jb2RlZCBpbiBwYWNrZXQNCiAgIGhlYWRlcnMuICBQQ04tZWdyZXNzLW5vZGVzIG1ha2UgbWVh c3VyZW1lbnRzIG9mIHRoZSBwYWNrZXQgbWFya2luZ3MNCiAgIGFuZCBzZW5kIGluZm9ybWF0aW9u IGFzIG5lY2Vzc2FyeSB0byB0aGUgbm9kZXMgdGhhdCBtYWtlIHRoZSBkZWNpc2lvbg0KICAgYWJv dXQgd2hpY2ggUENOLWZsb3dzIHRvIGFjY2VwdC9yZWplY3Qgb3IgdGVybWluYXRlLCBiYXNlZCBv biB0aGlzDQogICBpbmZvcm1hdGlvbi4gIEFub3RoZXIgZG9jdW1lbnQgd2lsbCBkZXNjcmliZSB0 aGUgZGVjaXNpb24tbWFraW5nDQogICBhbGdvcml0aG1zLiAgT3ZlcmFsbCB0aGUgYWltIGlzIHRv IGVuYWJsZSBQQ04tbm9kZXMgdG8gZ2l2ZSBhbiAiZWFybHkNCiAgIHdhcm5pbmciIG9mIHBvdGVu dGlhbCBjb25nZXN0aW9uIGJlZm9yZSB0aGVyZSBpcyBhbnkgc2lnbmlmaWNhbnQNCiAgIGJ1aWxk LXVwIG9mIFBDTi1wYWNrZXRzIGluIHRoZSBxdWV1ZTsgdGhlIGFkbWlzc2lvbiBjb250cm9sIG1l Y2hhbmlzbQ0KICAgbGltaXRzIHRoZSBQQ04tdHJhZmZpYyBvbiBlYWNoIGxpbmsgdG8gKnJvdWdo bHkqIGl0cyBQQ04tbG93ZXItcmF0ZQ0KICAgYW5kIHRoZSBmbG93IHRlcm1pbmF0aW9uIG1lY2hh bmlzbSBsaW1pdHMgdGhlIFBDTi10cmFmZmljIG9uIGVhY2gNCiAgIGxpbmsgdG8gKnJvdWdobHkq IGl0cyBQQ04tdXBwZXItcmF0ZS4NCg0KICAgV2UgYmVsaWV2ZSB0aGF0IHRoZSBrZXkgYmVuZWZp dHMgb2YgdGhlIFBDTiBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBh cmUgdGhhdCB0aGV5IGFyZSBzaW1wbGUsIHNjYWxhYmxlLCBhbmQgcm9idXN0IGJlY2F1c2U6DQoN CiAgIG8gIFBlciBmbG93IHN0YXRlIGlzIG9ubHkgcmVxdWlyZWQgYXQgdGhlIFBDTi1pbmdyZXNz LW5vZGVzDQogICAgICAoInN0YXRlbGVzcyBjb3JlIikuICBUaGlzIGlzIHJlcXVpcmVkIGZvciBw b2xpY2luZyBwdXJwb3NlcyAodG8NCiAgICAgIHByZXZlbnQgbm9uLWFkbWl0dGVkIFBDTiB0cmFm ZmljIGZyb20gZW50ZXJpbmcgdGhlIFBDTi1kb21haW4pIGFuZA0KICAgICAgc28gb24uICBJdCBp cyBub3QgZ2VuZXJhbGx5IHJlcXVpcmVkIHRoYXQgb3RoZXIgbmV0d29yayBlbnRpdGllcw0KICAg ICAgYXJlIGF3YXJlIG9mIGluZGl2aWR1YWwgZmxvd3MgKGFsdGhvdWdoIHRoZXkgbWF5IGJlIGlu IHBhcnRpY3VsYXINCiAgICAgIGRlcGxveW1lbnQgc2NlbmFyaW9zKS4NCg0KDQoNCg0KDQpFYXJk bGV5IChFZGl0b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDksIDIwMDggICAgICAgICAgICAg ICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgRG9jdW1lbnQg ICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIG8gIEFkbWlzc2lvbiBjb250 cm9sIGlzIHJlc2lsaWVudDogUW9TIHJlc2VydmF0aW9ucyBhcmUgZGVjb3VwbGVkDQogICAgICBm cm9tIHRoZSByb3V0aW5nIHN5c3RlbSBhbmQgc28gaW4gZ2VuZXJhbCBhZG1pdHRlZCBmbG93cyBj YW4NCiAgICAgIHN1cnZpdmUgY2FwYWNpdHksIHJvdXRpbmcgb3IgdG9wb2xvZ3kgY2hhbmdlcyB3 aXRob3V0IGFkZGl0aW9uYWwNCiAgICAgIHNpZ25hbGxpbmcuICBUaGUgUENOLWxvd2VyLXJhdGVz IGNhbiBiZSBjaG9zZW4gc21hbGwgZW5vdWdoIHRoYXQNCiAgICAgIGFkbWl0dGVkIHRyYWZmaWMg Y2FuIHN0aWxsIGJlIGNhcnJpZWQgYWZ0ZXIgYSByZXJvdXRpbmcgaW4gbW9zdA0KICAgICAgZmFp bHVyZSBjYXNlcy4gIFRoaXMgaXMgYW4gaW1wb3J0YW50IGZlYXR1cmUgYXMgUW9TIHZpb2xhdGlv bnMgaW4NCiAgICAgIGNvcmUgbmV0d29ya3MgZHVlIHRvIGxpbmsgZmFpbHVyZXMgYXJlIG1vcmUg bGlrZWx5IHRoYW4gUW9TDQogICAgICB2aW9sYXRpb25zIGR1ZSB0byBpbmNyZWFzZWQgdHJhZmZp YyB2b2x1bWUsIFtJeWVyXS4NCg0KICAgbyAgVGhlIFBDTi1tYXJraW5nIGFsZ29yaXRobXMgb25s eSBvcGVyYXRlIG9uIHRoZSBvdmVyYWxsIFBDTi10cmFmZmljDQogICAgICBvbiB0aGUgbGluaywg bm90IHBlciBmbG93Lg0KDQogICBvICBUaGUgaW5mb3JtYXRpb24gb2YgdGhlc2UgbWVhc3VyZW1l bnRzIGlzIHNpZ25hbGxlZCB0byB0aGUgUENOLQ0KICAgICAgZWdyZXNzLW5vZGVzIGJ5IHRoZSBQ Q04tbWFya3MgaW4gdGhlIHBhY2tldCBoZWFkZXJzLiAgTm8NCiAgICAgIGFkZGl0aW9uYWwgc2ln bmFsbGluZyBwcm90b2NvbCBpcyByZXF1aXJlZCBmb3IgdHJhbnNwb3J0aW5nIHRoZQ0KICAgICAg UENOLW1hcmtzLiAgVGhlcmVmb3JlIG5vIHNlY3VyZSBiaW5kaW5nIGlzIHJlcXVpcmVkIGJldHdl ZW4gZGF0YQ0KICAgICAgcGFja2V0cyBhbmQgc2VwYXJhdGUgY29uZ2VzdGlvbiBtZXNzYWdlcy4N Cg0KICAgbyAgVGhlIFBDTi1lZ3Jlc3Mtbm9kZXMgbWFrZSBzZXBhcmF0ZSBtZWFzdXJlbWVudHMs IG9wZXJhdGluZyBvbiB0aGUNCiAgICAgIG92ZXJhbGwgUENOLXRyYWZmaWMsIGZvciBlYWNoIFBD Ti1pbmdyZXNzLW5vZGUsIGllIG5vdCBwZXIgZmxvdy4NCiAgICAgIFNpbWlsYXJseSwgc2lnbmFs bGluZyBieSB0aGUgUENOLWVncmVzcy1ub2RlIG9mIFBDTi1mZWVkYmFjay0NCiAgICAgIGluZm9y bWF0aW9uICh3aGljaCBpcyB1c2VkIGZvciBmbG93IGFkbWlzc2lvbiBhbmQgdGVybWluYXRpb24N CiAgICAgIGRlY2lzaW9ucykgaXMgYXQgdGhlIGdyYW51bGFyaXR5IG9mIHRoZSBpbmdyZXNzLWVn cmVzcy1hZ2dyZWdhdGUuDQoNCiAgIG8gIFRoZSBhZG1pdHRlZCBQQ04tbG9hZCBpcyBjb250cm9s bGVkIGR5bmFtaWNhbGx5LiAgVGhlcmVmb3JlIGl0DQogICAgICBhZGFwdHMgYXMgdGhlIHRyYWZm aWMgbWF0cml4IGNoYW5nZXMsIGFuZCBhbHNvIGlmIHRoZSBuZXR3b3JrDQogICAgICB0b3BvbG9n eSBjaGFuZ2VzIChlZyBhZnRlciBhIGxpbmsgZmFpbHVyZSkuICBIZW5jZSBhbiBvcGVyYXRvciBj YW4NCiAgICAgIGJlIGxlc3MgY29uc2VydmF0aXZlIHdoZW4gZGVwbG95aW5nIG5ldHdvcmsgY2Fw YWNpdHksIGFuZCBsZXNzDQogICAgICBhY2N1cmF0ZSBpbiB0aGVpciBwcmVkaWN0aW9uIG9mIHRo ZSBQQ04tdHJhZmZpYyBtYXRyaXguDQoNCiAgIG8gIFRoZSB0ZXJtaW5hdGlvbiBtZWNoYW5pc20g Y29tcGxlbWVudHMgYWRtaXNzaW9uIGNvbnRyb2wuICBJdA0KICAgICAgYWxsb3dzIHRoZSBuZXR3 b3JrIHRvIHJlY292ZXIgZnJvbSBzdWRkZW4gdW5leHBlY3RlZCBzdXJnZXMgb2YNCiAgICAgIFBD Ti10cmFmZmljIG9uIHNvbWUgbGlua3MsIHRodXMgcmVzdG9yaW5nIFFvUyB0byB0aGUgcmVtYWlu aW5nDQogICAgICBmbG93cy4gIFN1Y2ggc2NlbmFyaW9zIGFyZSBleHBlY3RlZCB0byBiZSByYXJl IGJ1dCBub3QgaW1wb3NzaWJsZS4NCiAgICAgIFRoZXkgY2FuIGJlIGNhdXNlZCBieSBsYXJnZSBu ZXR3b3JrIGZhaWx1cmVzIHRoYXQgcmVkaXJlY3QgbG90cyBvZg0KICAgICAgYWRtaXR0ZWQgUENO LXRyYWZmaWMgdG8gb3RoZXIgbGlua3MsIG9yIGJ5IG1hbGZ1bmN0aW9uIG9mIHRoZQ0KICAgICAg bWVhc3VyZW1lbnQtYmFzZWQgYWRtaXNzaW9uIGNvbnRyb2wgaW4gdGhlIHByZXNlbmNlIG9mIGFk bWl0dGVkDQogICAgICBmbG93cyB0aGF0IHNlbmQgZm9yIGEgd2hpbGUgd2l0aCBhbiBhdHlwaWNh bGx5IGxvdyByYXRlIGFuZCB0aGVuDQogICAgICBpbmNyZWFzZSB0aGVpciByYXRlcyBpbiBhIGNv cnJlbGF0ZWQgd2F5Lg0KDQogICBvICBUaGUgUENOLXVwcGVyLXJhdGUgbWF5IGJlIHNldCBiZWxv dyB0aGUgbWF4aW11bSByYXRlIHRoYXQgUENOLQ0KICAgICAgdHJhZmZpYyBjYW4gYmUgdHJhbnNt aXR0ZWQgb24gYSBsaW5rLCBpbiBvcmRlciB0byB0cmlnZ2VyDQogICAgICB0ZXJtaW5hdGlvbiBv ZiBzb21lIFBDTi1mbG93cyBiZWZvcmUgbG9zcyBvZiBQQ04tcGFja2V0cyBvY2N1cnMgb3INCiAg ICAgIHRvIGtlZXAgdGhlIG1heGltdW0gUENOLWxvYWQgb24gYSBsaW5rIGJlbG93IGEgbGV2ZWwg Y29uZmlndXJlZCBieQ0KICAgICAgdGhlIG9wZXJhdG9yLg0KDQogICBPcGVyYXRvcnMgb2YgbmV0 d29ya3Mgd2lsbCB3YW50IHRvIHVzZSB0aGUgUENOIG1lY2hhbmlzbXMgaW4gdmFyaW91cw0KICAg YXJyYW5nZW1lbnRzLCBmb3IgaW5zdGFuY2UgZGVwZW5kaW5nIG9uIGhvdyB0aGV5IGFyZSBwZXJm b3JtaW5nDQoNCg0KDQpFYXJkbGV5IChFZGl0b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDks IDIwMDggICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgRG9jdW1lbnQgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAg IGFkbWlzc2lvbiBjb250cm9sIG91dHNpZGUgdGhlIFBDTi1kb21haW4gKHVzZXJzIGFmdGVyIGFs bCBhcmUNCiAgIGNvbmNlcm5lZCBhYm91dCBRb1MgZW5kLXRvLWVuZCksIHdoYXQgdGhlaXIgcGFy dGljdWxhciBnb2FscyBhbmQNCiAgIGFzc3VtcHRpb25zIGFyZSwgYW5kIHNvIG9uLiAgU2V2ZXJh bCBkZXBsb3ltZW50IG1vZGVscyBhcmUgcG9zc2libGU6DQoNCiAgIG8gIEFuIG9wZXJhdG9yIG1h eSBjaG9vc2UgdG8gZGVwbG95IGVpdGhlciBhZG1pc3Npb24gY29udHJvbCBvciBmbG93DQogICAg ICB0ZXJtaW5hdGlvbiBvciBib3RoIChzZWUgU2VjdGlvbiA3LjIpLg0KDQogICBvICBJbnRTZXJ2 IG92ZXIgRGlmZlNlcnYgW1JGQzI5OThdLiAgVGhlIERpZmZTZXJ2IHJlZ2lvbiBpcyBQQ04tDQog ICAgICBlbmFibGVkLCBSU1ZQIHNpZ25hbGxpbmcgaXMgdXNlZCBlbmQtdG8tZW5kIGFuZCB0aGUg UENOLWRvbWFpbiBpcw0KICAgICAgYSBzaW5nbGUgUlNWUCBob3AsIGllIG9ubHkgdGhlIFBDTi1i b3VuZGFyeS1ub2RlcyBwcm9jZXNzIFJTVlANCiAgICAgIG1lc3NhZ2VzLiAgT3V0c2lkZSB0aGUg UENOLWRvbWFpbiBSU1ZQIG1lc3NhZ2VzIGFyZSBwcm9jZXNzZWQgb24NCiAgICAgIGVhY2ggaG9w LiAgVGhpcyBpcyBkZXNjcmliZWQgaW4NCiAgICAgIFtJLUQuYnJpc2NvZS10c3Z3Zy1jbC1hcmNo aXRlY3R1cmVdDQoNCiAgIG8gIFJTVlAgc2lnbmFsbGluZyBpcyBvcmlnaW5hdGVkIGFuZC9vciB0 ZXJtaW5hdGVkIGJ5IHByb3hpZXMsIHdpdGgNCiAgICAgIGFwcGxpY2F0aW9uLWxheWVyIHNpZ25h bGxpbmcgYmV0d2VlbiB0aGUgZW5kIHVzZXIgYW5kIHRoZSBwcm94eS4NCiAgICAgIEZvciBpbnN0 YW5jZSBTSVAgc2lnbmFsbGluZyB3aXRoIGEgaG9tZSBodWIuDQoNCiAgIG8gIFNpbWlsYXIgdG8g cHJldmlvdXMgYnVsbGV0cyBidXQgTlNJUyBzaWduYWxsaW5nIGlzIHVzZWQgaW5zdGVhZCBvZg0K ICAgICAgUlNWUC4NCg0KICAgbyAgTk9URTogQ29uc2lkZXJhdGlvbiBvZiBzaWduYWxsaW5nIGV4 dGVuc2lvbnMgZm9yIHNwZWNpZmljDQogICAgICBwcm90b2NvbHMgaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhlIFBDTiBXRywgaG93ZXZlciBpdCB3aWxsDQogICAgICBwcm9kdWNlIGEgIlJlcXVp cmVtZW50cyBmb3Igc2lnbmFsbGluZyIgZG9jdW1lbnQgYXMgcG90ZW50aWFsDQogICAgICBpbnB1 dCBmb3IgdGhlIGFwcHJvcHJpYXRlIFdHcy4NCg0KICAgbyAgRGVwZW5kaW5nIG9uIHRoZSBkZXBs b3ltZW50IHNjZW5hcmlvLCB0aGUgZGVjaXNpb24tbWFraW5nDQogICAgICBmdW5jdGlvbmFsaXR5 IChhYm91dCBmbG93IGFkbWlzc2lvbiBhbmQgdGVybWluYXRpb24pIGNvdWxkIHJlc2lkZQ0KICAg ICAgYXQgdGhlIFBDTi1pbmdyZXNzLW5vZGVzIG9yIFBDTi1lZ3Jlc3Mtbm9kZXMgb3IgYXQgc29t ZSBjZW50cmFsDQogICAgICBjb250cm9sIG5vZGUgaW4gdGhlIFBDTi1kb21haW4uICBOT1RFOiBU aGUgQ2hhcnRlciByZXN0cmljdHMgdXMgdG8NCiAgICAgIGNvbnNpZGVyaW5nIHdoZW4gZnVuY3Rp b25hbGl0eSBpcyBhdCB0aGUgUENOLWJvdW5kYXJ5LW5vZGVzLg0KDQogICBvICBUaGVyZSBhcmUg c2V2ZXJhbCBQQ04tZG9tYWlucyBvbiB0aGUgZW5kLXRvLWVuZCBwYXRoLCBlYWNoDQogICAgICBv cGVyYXRpbmcgUENOIG1lY2hhbmlzbXMgaW5kZXBlbmRlbnRseS4gIE5PVEU6IFRoZSBDaGFydGVy DQogICAgICByZXN0cmljdHMgdXMgdG8gY29uc2lkZXJpbmcgYSBzaW5nbGUgUENOLWRvbWFpbi4g IEEgcG9zc2liaWxpdHkNCiAgICAgIGFmdGVyIHJlLWNoYXJ0ZXJpbmcgaXMgdG8gY29uc2lkZXIg b3BlcmF0aW5nIFBDTiBvdmVyIGNvbmNhdGVuYXRlZA0KICAgICAgRGlmZlNlcnYgZG9tYWlucyB0 aGF0IGRvbid0IHRydXN0IGVhY2ggb3RoZXIgKGllIHdlYWtlbnMNCiAgICAgIEFzc3VtcHRpb24g MSBhYm91dCB0cnVzdCwgc2VlIFNlY3Rpb24gMy4xKQ0KDQogICBvICBUaGUgUENOLWRvbWFpbiBl eHRlbmRzIHRvIHRoZSBlbmQgdXNlcnMuICBOT1RFOiBUaGlzIGlzIG91dHNpZGUNCiAgICAgIHRo ZSBDaGFydGVyIGJlY2F1c2UgaXQgYnJlYWtzIEFzc3VtcHRpb24gMyAoYWdncmVnYXRpb24sIHNl ZQ0KICAgICAgbGF0ZXI7IGluY2lkZW50YWxseSBpdCBkb2Vzbid0IG5lY2Vzc2FyaWx5IGJyZWFr IEFzc3VtcHRpb24gMQ0KICAgICAgKHRydXN0KSwgYmVjYXVzZSBpbiBzb21lIGVudmlyb25tZW50 cywgZWcgY29ycG9yYXRlLCB0aGUgZW5kIHVzZXINCiAgICAgIG1heSBoYXZlIGEgY29udHJvbGxl ZCBjb25maWd1cmF0aW9uIGFuZCBzbyBiZSB0cnVzdGVkKS4gIFRoZQ0KICAgICAgc2NlbmFyaW8g aXMgZGVzY3JpYmVkIGluIFtJLUQuYmFiaWFyei1wY24tc2lwLWNhcF0uDQoNCiAgIG8gIFBzZXVk b3dpcmU6IFBDTiBtYXkgYmUgdXNlZCBhcyBhIGNvbmdlc3Rpb24gYXZvaWRhbmNlIG1lY2hhbmlz bQ0KICAgICAgZm9yIGVkZ2UgdG8gZWRnZSBwc2V1ZG93aXJlIGVtdWxhdGlvbnMNCg0KDQoNCkVh cmRsZXkgKEVkaXRvcikgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAg ICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBEb2N1bWVu dCAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgICAgW0ktRC5pZXRmLXB3 ZTMtY29uZ2VzdGlvbi1mcm13a10uICBOT1RFOiBTcGVjaWZpYyBjb25zaWRlcmF0aW9uIG9mDQog ICAgICBwc2V1ZG93aXJlcyBpcyBub3QgaW4gdGhlIFBDTiBXRyBDaGFydGVyLg0KDQogICBvICBN UExTOiBbUkZDMzI3MF0gZGVmaW5lcyBob3cgdG8gc3VwcG9ydCB0aGUgRGlmZlNlcnYgYXJjaGl0 ZWN0dXJlDQogICAgICBpbiBNUExTIG5ldHdvcmtzLiAgW0ktRC5pZXRmLXRzdndnLWVjbi1tcGxz XSBkZXNjcmliZXMgaG93IHRvIGFkZA0KICAgICAgUENOIGZvciBhZG1pc3Npb24gY29udHJvbCBv ZiBtaWNyb2Zsb3dzIGludG8gYSBzZXQgb2YgTVBMUy1URQ0KICAgICAgYWdncmVnYXRlcyAoTXVs dGktcHJvdG9jb2wgbGFiZWwgc3dpdGNoaW5nIHRyYWZmaWMgZW5naW5lZXJpbmcpLg0KICAgICAg UENOLW1hcmtpbmcgaXMgZG9uZSBpbiBNUExTJ3MgRVhQIGZpZWxkLiAgTk9URTogVGhpcyBkcmFm dCBpcyBhDQogICAgICBUU1YgV0cgZHJhZnQsIGFuZCBpcyBhbHNvIGJlaW5nIHJldmlld2VkIGlu IHRoZSBNUExTIFdHLg0KDQogICBvICBTaW1pbGFybHksIGl0IG1heSBiZSBwb3NzaWJsZSB0byBl eHRlbmQgUENOIGludG8gRXRoZXJuZXQNCiAgICAgIG5ldHdvcmtzLCB3aGVyZSBQQ04tbWFya2lu ZyBpcyBkb25lIGluIHRoZSBFdGhlcm5ldCBoZWFkZXIuICBOT1RFOg0KICAgICAgU3BlY2lmaWMg Y29uc2lkZXJhdGlvbiBvZiB0aGlzIGV4dGVuc2lvbiBpcyBvdXRzaWRlIHRoZSBQQ04gV0cNCiAg ICAgIENoYXJ0ZXIuDQoNCg0KMi4gIFRlcm1pbm9sb2d5DQoNCiAgIG8gIFBDTi1kb21haW46IGEg UENOLWNhcGFibGUgRGlmZlNlcnYgZG9tYWluOyBhIGNvbnRpZ3VvdXMgc2V0IG9mDQogICAgICBQ Q04tZW5hYmxlZCBEaWZmU2VydiBub2Rlcy4NCg0KICAgbyAgUENOLWJvdW5kYXJ5LW5vZGU6IGEg bm9kZSB0aGF0IGNvbm5lY3RzIG9uZSBQQ04tZG9tYWluIHRvIGEgbm9kZQ0KICAgICAgZWl0aGVy IGluIGFub3RoZXIgUENOLWRvbWFpbiBvciBpbiBhIG5vbiBQQ04tZG9tYWluLg0KDQogICBvICBQ Q04taW50ZXJpb3Itbm9kZTogYSBub2RlIGluIGEgUENOLWRvbWFpbiB0aGF0IGlzIG5vdCBhIFBD Ti0NCiAgICAgIGJvdW5kYXJ5LW5vZGUuDQoNCiAgIG8gIFBDTi1ub2RlOiBhIFBDTi1ib3VuZGFy eS1ub2RlIG9yIGEgUENOLWludGVyaW9yLW5vZGUNCg0KICAgbyAgUENOLWVncmVzcy1ub2RlOiBh IFBDTi1ib3VuZGFyeS1ub2RlIGluIGl0cyByb2xlIGluIGhhbmRsaW5nDQogICAgICB0cmFmZmlj IGFzIGl0IGxlYXZlcyBhIFBDTi1kb21haW4uDQoNCiAgIG8gIFBDTi1pbmdyZXNzLW5vZGU6IGEg UENOLWJvdW5kYXJ5LW5vZGUgaW4gaXRzIHJvbGUgaW4gaGFuZGxpbmcNCiAgICAgIHRyYWZmaWMg YXMgaXQgZW50ZXJzIGEgUENOLWRvbWFpbi4NCg0KICAgbyAgUENOLXRyYWZmaWM6IEEgUENOLWRv bWFpbiBjYXJyaWVzIHRyYWZmaWMgb2YgZGlmZmVyZW50IERpZmZTZXJ2DQogICAgICBjbGFzc2Vz IFtSRkM0NTk0XS4gIFRob3NlIHVzaW5nIHRoZSBQQ04gbWVjaGFuaXNtcyBhcmUgY2FsbGVkIFBD Ti0NCiAgICAgIGNsYXNzZXMgKGNvbGxlY3RpdmVseSBjYWxsZWQgUENOLXRyYWZmaWMpIGFuZCB0 aGUgY29ycmVzcG9uZGluZw0KICAgICAgcGFja2V0cyBhcmUgUENOLXBhY2tldHMuICBUaGUgc2Ft ZSBuZXR3b3JrIG1heSBjYXJyeSB0cmFmZmljIHVzaW5nDQogICAgICBvdGhlciBEaWZmU2VydiBj bGFzc2VzLg0KDQogICBvICBJbmdyZXNzLWVncmVzcy1hZ2dyZWdhdGU6IFRoZSBjb2xsZWN0aW9u IG9mIFBDTi1wYWNrZXRzIGZyb20gYWxsDQogICAgICBQQ04tZmxvd3MgdGhhdCB0cmF2ZWwgaW4g b25lIGRpcmVjdGlvbiBiZXR3ZWVuIGEgc3BlY2lmaWMgcGFpciBvZg0KICAgICAgUENOLWJvdW5k YXJ5LW5vZGVzLg0KDQogICBvICBQQ04tbG93ZXItcmF0ZTogYSByZWZlcmVuY2UgcmF0ZSBjb25m aWd1cmVkIGZvciBlYWNoIGxpbmsgaW4gdGhlDQogICAgICBQQ04tZG9tYWluLCB3aGljaCBpcyBs b3dlciB0aGFuIHRoZSBQQ04tdXBwZXItcmF0ZS4gIEl0IGlzIHVzZWQgYnkNCiAgICAgIGFuIGFs Z29yaXRobSB0aGF0IGRldGVybWluZXMgd2hldGhlciBhIHBhY2tldCBzaG91bGQgYmUgUENOLW1h cmtlZA0KDQoNCg0KRWFyZGxleSAoRWRpdG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAy MDA4ICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIERvY3VtZW50ICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICAg ICB3aXRoIGEgZmlyc3QgZW5jb2RpbmcuDQoNCiAgIG8gIFBDTi11cHBlci1yYXRlOiBhIHJlZmVy ZW5jZSByYXRlIGNvbmZpZ3VyZWQgZm9yIGVhY2ggbGluayBpbiB0aGUNCiAgICAgIFBDTi1kb21h aW4sIHdoaWNoIGlzIGhpZ2hlciB0aGFuIHRoZSBQQ04tbG93ZXItcmF0ZS4gIEl0IGlzIHVzZWQN CiAgICAgIGJ5IGFuIGFsZ29yaXRobSB0aGF0IGRldGVybWluZXMgd2hldGhlciBhIHBhY2tldCBz aG91bGQgYmUgUENOLQ0KICAgICAgbWFya2VkIHdpdGggYSBzZWNvbmQgZW5jb2RpbmcuDQoNCiAg IG8gIFRocmVzaG9sZC1tYXJraW5nOiBhIFBDTi1tYXJraW5nIGFsZ29yaXRobSBzdWNoIHRoYXQg YWxsIFBDTi0NCiAgICAgIHRyYWZmaWMgaXMgbWFya2VkIGlmIHRoZSBQQ04tdHJhZmZpYyBleGNl ZWRzIGEgcGFydGljdWxhciByYXRlDQogICAgICAoZWl0aGVyIHRoZSBQQ04tbG93ZXItcmF0ZSBv ciBQQ04tdXBwZXItcmF0ZSkuICBOT1RFOiBUaGUNCiAgICAgIGRlZmluaXRpb24gcmVmbGVjdHMg dGhlIG92ZXJhbGwgaW50ZW50IG9mIHRoZSBhbGdvcml0aG0gcmF0aGVyDQogICAgICB0aGFuIGl0 cyBpbnN0YW50YW5lb3VzIGJlaGF2aW91ciwgc2luY2UgdGhlIHJhdGUgbWVhc3VyZWQgYXQgYQ0K ICAgICAgcGFydGljdWxhciBtb21lbnQgZGVwZW5kcyBvbiB0aGUgYWxnb3JpdGhtLCBpdHMgaW1w bGVtZW50YXRpb24gYW5kDQogICAgICB0aGUgdHJhZmZpYydzIHZhcmlhbmNlIGFzIHdlbGwgYXMg aXRzIHJhdGUuDQoNCiAgIG8gIEV4Y2Vzcy1yYXRlLW1hcmtpbmc6IGEgUENOLW1hcmtpbmcgYWxn b3JpdGhtIHN1Y2ggdGhhdCB0aGUgYW1vdW50DQogICAgICBvZiBQQ04tdHJhZmZpYyB0aGF0IGlz IFBDTi1tYXJrZWQgaXMgZXF1YWwgdG8gdGhlIGFtb3VudCB0aGF0DQogICAgICBleGNlZWRzIGEg cGFydGljdWxhciByYXRlIChlaXRoZXIgdGhlIFBDTi1sb3dlci1yYXRlIG9yIFBDTi11cHBlci0N CiAgICAgIHJhdGUpLiAgTk9URTogVGhlIGRlZmluaXRpb24gcmVmbGVjdHMgdGhlIG92ZXJhbGwg aW50ZW50IG9mIHRoZQ0KICAgICAgYWxnb3JpdGhtIHJhdGhlciB0aGFuIGl0cyBpbnN0YW50YW5l b3VzIGJlaGF2aW91ciwgc2luY2UgdGhlIHJhdGUNCiAgICAgIG1lYXN1cmVkIGF0IGEgcGFydGlj dWxhciBtb21lbnQgZGVwZW5kcyBvbiB0aGUgYWxnb3JpdGhtLCBpdHMNCiAgICAgIGltcGxlbWVu dGF0aW9uIGFuZCB0aGUgdHJhZmZpYydzIHZhcmlhbmNlIGFzIHdlbGwgYXMgaXRzIHJhdGUuDQoN CiAgIG8gIFByZS1jb25nZXN0aW9uOiBhIGNvbmRpdGlvbiBvZiBhIGxpbmsgd2l0aGluIGEgUENO LWRvbWFpbiBpbiB3aGljaA0KICAgICAgdGhlIFBDTi1ub2RlIHBlcmZvcm1zIFBDTi1tYXJraW5n LCBpbiBvcmRlciB0byBwcm92aWRlIGFuICJlYXJseQ0KICAgICAgd2FybmluZyIgb2YgcG90ZW50 aWFsIGNvbmdlc3Rpb24gYmVmb3JlIHRoZXJlIGlzIGFueSBzaWduaWZpY2FudA0KICAgICAgYnVp bGQtdXAgb2YgUENOLXBhY2tldHMgaW4gdGhlIHF1ZXVlLg0KDQogICBvICBQQ04tbWFya2luZzog dGhlIHByb2Nlc3Mgb2Ygc2V0dGluZyB0aGUgaGVhZGVyIGluIGEgUENOLXBhY2tldA0KICAgICAg YmFzZWQgb24gZGVmaW5lZCBydWxlcywgaW4gcmVhY3Rpb24gdG8gcHJlLWNvbmdlc3Rpb24uDQoN CiAgIG8gIHt7aWYgbmVjZXNzYXJ5OiBQQ04tbG93ZXItcmF0ZS1tYXJraW5nIGFuZCBQQ04tdXBw ZXItcmF0ZS0NCiAgICAgIG1hcmtpbmd9fQ0KDQogICBvICBQQ04tZmVlZGJhY2staW5mb3JtYXRp b246IGluZm9ybWF0aW9uIHNpZ25hbGxlZCBieSBhIFBDTi1lZ3Jlc3MtDQogICAgICBub2RlIHRv IGEgUENOLWluZ3Jlc3Mtbm9kZSBvciBjZW50cmFsIGNvbnRyb2wgbm9kZSwgd2hpY2ggaXMNCiAg ICAgIG5lZWRlZCBmb3IgdGhlIGZsb3cgYWRtaXNzaW9uIGFuZCBmbG93IHRlcm1pbmF0aW9uIG1l Y2hhbmlzbXMuDQoNCg0KMy4gIEFzc3VtcHRpb25zIGFuZCBjb25zdHJhaW50cyBvbiBzY29wZQ0K DQogICBUaGUgUENOIFdHJ3MgY2hhcnRlciByZXN0cmljdHMgdGhlIGluaXRpYWwgc2NvcGUgYnkg YSBzZXQgb2YNCiAgIGFzc3VtcHRpb25zLiAgSGVyZSB3ZSBsaXN0IHRob3NlIGFzc3VtcHRpb25z IGFuZCBleHBsYWluIHRoZW0uDQoNCiAgIDEuICB0aGVzZSBjb21wb25lbnRzIGFyZSBkZXBsb3ll ZCBpbiBhIHNpbmdsZSBEaWZmU2VydiBkb21haW4sIHdpdGhpbg0KICAgICAgIHdoaWNoIGFsbCBQ Q04tbm9kZXMgYXJlIFBDTi1lbmFibGVkIGFuZCB0cnVzdCBlYWNoIG90aGVyIGZvcg0KICAgICAg IHRydXRoZnVsIFBDTi1tYXJraW5nIGFuZCB0cmFuc3BvcnQNCg0KDQoNCg0KRWFyZGxleSAoRWRp dG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAgICAgICAgIFtQYWdl IDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3VtZW50ICAgICAgICAg ICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICAyLiAgYWxsIGZsb3dzIGhhbmRsZWQgYnkg dGhlc2UgbWVjaGFuaXNtcyBhcmUgaW5lbGFzdGljIGFuZA0KICAgICAgIGNvbnN0cmFpbmVkIHRv IGEga25vd24gcGVhayByYXRlIHRocm91Z2ggcG9saWNpbmcgb3Igc2hhcGluZw0KDQogICAzLiAg dGhlIG51bWJlciBvZiBQQ04tZmxvd3MgYWNyb3NzIGFueSBwb3RlbnRpYWwgYm90dGxlbmVjayBs aW5rIGlzDQogICAgICAgc3VmZmljaWVudGx5IGxhcmdlIHRoYXQgc3RhdGVsZXNzLCBzdGF0aXN0 aWNhbCBtZWNoYW5pc21zIGNhbiBiZQ0KICAgICAgIGVmZmVjdGl2ZS4gIFRvIHB1dCBpdCBhbm90 aGVyIHdheSwgdGhlIGFnZ3JlZ2F0ZSBiaXQgcmF0ZSBvZiBQQ04tDQogICAgICAgdHJhZmZpYyBh Y3Jvc3MgYW55IHBvdGVudGlhbCBib3R0bGVuZWNrIGxpbmsgbmVlZHMgdG8gYmUNCiAgICAgICBz dWZmaWNpZW50bHkgbGFyZ2UgcmVsYXRpdmUgdG8gdGhlIG1heGltdW0gYWRkaXRpb25hbCBiaXQg cmF0ZQ0KICAgICAgIGFkZGVkIGJ5IG9uZSBmbG93DQoNCiAgIDQuICBQQ04tZmxvd3MgbWF5IGhh dmUgZGlmZmVyZW50IHByZWNlZGVuY2UsIGJ1dCB0aGUgYXBwbGljYWJpbGl0eSBvZg0KICAgICAg IHRoZSBQQ04gbWVjaGFuaXNtcyBmb3IgZW1lcmdlbmN5IHVzZSAoOTExLCBHRVRTLCBXUFMsIE1M UFAsIGV0Yy4pDQogICAgICAgaXMgb3V0IG9mIHNjb3BlDQoNCiAgIEFmdGVyIGNvbXBsZXRpb24g b2YgdGhlIGluaXRpYWwgcGhhc2UsIHRoZSBQQ04gV0cgbWF5IHJlLWNoYXJ0ZXIgdG8NCiAgIGRl dmVsb3Agc29sdXRpb25zIGZvciBzcGVjaWZpYyBzY2VuYXJpb3Mgd2hlcmUgc29tZSBvZiB0aGVz ZQ0KICAgcmVzdHJpY3Rpb25zIGFyZSBub3QgaW4gcGxhY2UuICBJdCBtYXkgYWxzbyByZS1jaGFy dGVyIHRvIGNvbnNpZGVyDQogICBhcHBseWluZyB0aGUgUENOIG1lY2hhbmlzbXMgdG8gYWRkaXRp b25hbCBkZXBsb3ltZW50IHNjZW5hcmlvcw0KICAgKG9wZXJhdGlvbiBvdmVyIGNvbmNhdGVuYXRl ZCBEaWZmU2VydiBkb21haW5zLCBQQ04tYXdhcmUgYXBwbGljYXRpb24NCiAgIG1lY2hhbmlzbXMg ZXRjLikuICBUaGUgV0cgbWF5IGFsc28gcmUtY2hhcnRlciB0byBpbnZlc3RpZ2F0ZQ0KICAgYWRk aXRpb25hbCByZXNwb25zZSBtZWNoYW5pc21zIHRoYXQgYWN0IG9uIChwcmUtKWNvbmdlc3Rpb24N CiAgIGluZm9ybWF0aW9uLiAgT25lIGV4YW1wbGUgY291bGQgYmUgZmxvdy1yYXRlIGFkYXB0YXRp b24gYnkgZWxhc3RpYw0KICAgYXBwbGljYXRpb25zIChyYXRoZXIgdGhhbiBmbG93IGFkbWlzc2lv biBvciB0ZXJtaW5hdGlvbikuICBBbm90aGVyDQogICBleGFtcGxlIG9mIGEgcG9zc2libGUgZnV0 dXJlIHdvcmsgaXRlbSBpcyB0aGUgb3BlcmF0aW9uIG9mIFBDTiBvdmVyDQogICBjb25jYXRlbmF0 ZWQgUENOLWRvbWFpbnMgdGhhdCBkb24ndCB0cnVzdCBlYWNoIG90aGVyIChwZXJoYXBzIHJlLQ0K ICAgRUNOLFtJLUQuYnJpc2NvZS1yZS1wY24tYm9yZGVyLWNoZWF0XSkuICBUaGUgZGV0YWlscyBv ZiB0aGVzZSB3b3JrDQogICBpdGVtcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIGluaXRp YWwgcGhhc2UsIGJ1dCB0aGUgV0cgbWF5DQogICBjb25zaWRlciB0aGVpciByZXF1aXJlbWVudHMg aW4gb3JkZXIgdG8gZGVzaWduIGNvbXBvbmVudHMgdGhhdCBhcmUNCiAgIHN1ZmZpY2llbnRseSBn ZW5lcmFsIHRvIHN1cHBvcnQgc3VjaCBleHRlbnNpb25zIGluIHRoZSBmdXR1cmUuICBUaGUNCiAg IHdvcmtpbmcgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBzdGFuZGFyZHMgZGV2ZWxvcGVkIGluIHRo ZSBpbml0aWFsDQogICBwaGFzZSBzaG91bGQgbm90IG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8gc2F0 aXNmeSB0aGUgc29sdXRpb25zIGZvcg0KICAgd2hlbiB0aGVzZSByZXN0cmljdGlvbnMgYXJlIHJl bW92ZWQuDQoNCjMuMS4gIEFzc3VtcHRpb24gMTogVHJ1c3QgLSBjb250cm9sbGVkIGVudmlyb25t ZW50DQoNCiAgIFdlIGFzc3VtZSB0aGF0IHRoZSBQQ04tZG9tYWluIGlzIGEgY29udHJvbGxlZCBl bnZpcm9ubWVudCwgaS5lLiBhbGwNCiAgIHRoZSBub2RlcyBpbiBhIFBDTi1kb21haW4gcnVuIFBD TiBhbmQgdHJ1c3QgZWFjaCBvdGhlci4gIFRoZXJlIGFyZQ0KICAgc2V2ZXJhbCByZWFzb25zIGZv ciBwcm9wb3NpbmcgdGhpcyBhc3N1bXB0aW9uOg0KDQogICBvICBUaGUgUENOLWRvbWFpbiBoYXMg dG8gYmUgZW5jaXJjbGVkIGJ5IGEgcmluZyBvZiBQQ04tYm91bmRhcnktDQogICAgICBub2Rlcywg b3RoZXJ3aXNlIFBDTi1wYWNrZXRzIGNvdWxkIGVudGVyIHRoZSBQQ04tZG9tYWluIHdpdGhvdXQN CiAgICAgIGJlaW5nIHN1YmplY3QgdG8gYWRtaXNzaW9uIGNvbnRyb2wsIHdoaWNoIHdvdWxkIHBv dGVudGlhbGx5DQogICAgICBkZXN0cm95IHRoZSBRb1Mgb2YgZXhpc3RpbmcgZmxvd3MuDQoNCiAg IG8gIFNpbWlsYXJseSwgYSBQQ04tYm91bmRhcnktbm9kZSBoYXMgdG8gdHJ1c3QgdGhhdCBhbGwg dGhlIFBDTi1ub2Rlcw0KICAgICAgYXJlIGRvaW5nIFBDTi1tYXJraW5nLiAgQSBub24gUENOLW5v ZGUgd291bGRuJ3QgYmUgYWJsZSB0byBhbGVydA0KICAgICAgdGhhdCBpdCBpcyBzdWZmZXJpbmcg cHJlLWNvbmdlc3Rpb24sIHdoaWNoIHBvdGVudGlhbGx5IHdvdWxkIGxlYWQNCiAgICAgIHRvIHRv byBtYW55IFBDTi1mbG93cyBiZWluZyBhZG1pdHRlZCAob3IgdG9vIGZldyBiZWluZw0KDQoNCg0K RWFyZGxleSAoRWRpdG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3Vt ZW50ICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICAgICB0ZXJtaW5hdGVk KS4gIFdvcnNlLCBhIHJvZ3VlIG5vZGUgY291bGQgcGVyZm9ybSB2YXJpb3VzIGF0dGFja3MsDQog ICAgICBhcyBkaXNjdXNzZWQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24u DQoNCiAgIE9uZSB3YXkgb2YgYXNzdXJpbmcgdGhlIGFib3ZlIHR3byBwb2ludHMgaXMgdGhhdCB0 aGUgZW50aXJlIFBDTi0NCiAgIGRvbWFpbiBpcyBydW4gYnkgYSBzaW5nbGUgb3BlcmF0b3IuICBB bm90aGVyIHBvc3NpYmlsaXR5IGlzIHRoYXQNCiAgIHRoZXJlIGFyZSBzZXZlcmFsIG9wZXJhdG9y cyBidXQgdGhleSB0cnVzdCBlYWNoIG90aGVyIHRvIGEgc3VmZmljaWVudA0KICAgbGV2ZWwsIGlu IHRoZWlyIGhhbmRsaW5nIG9mIFBDTi10cmFmZmljLg0KDQozLjIuICBBc3N1bXB0aW9uIDI6IFJl YWwtdGltZSBhcHBsaWNhdGlvbnMNCg0KICAgV2UgYXNzdW1lIHRoYXQgUENOLXBhY2tldHMgY29t ZSBmcm9tIHJlYWwgdGltZSBhcHBsaWNhdGlvbnMNCiAgIGdlbmVyYXRpbmcgaW5lbGFzdGljIHRy YWZmaWMgW1NoZW5rZXJdIGxpa2Ugdm9pY2UgYW5kIHZpZGVvIHJlcXVpcmluZw0KICAgbG93IGRl bGF5LCBqaXR0ZXIgYW5kIHBhY2tldCBsb3NzLCBmb3IgZXhhbXBsZSB0aGUgQ29udHJvbGxlZCBM b2FkDQogICBTZXJ2aWNlLCBbUkZDMjIxMV0sIGFuZCB0aGUgVGVsZXBob255IHNlcnZpY2UgY2xh c3MsIFtSRkM0NTk0XS4gIFRoaXMNCiAgIGFzc3VtcHRpb24gaXMgdG8gaGVscCBmb2N1cyB0aGUg ZWZmb3J0IHdoZXJlIGl0IGxvb2tzIGxpa2UgUENOIHdvdWxkDQogICBiZSBtb3N0IHVzZWZ1bCwg aWUgdGhlIHNvcnRzIG9mIGFwcGxpY2F0aW9ucyB3aGVyZSBwZXIgZmxvdyBRb1MgaXMgYQ0KICAg a25vd24gcmVxdWlyZW1lbnQuICBGb3IgaW5zdGFuY2UsIHRoZSBpbXBhY3Qgb2YgdGhpcyBhc3N1 bXB0aW9uIHdvdWxkDQogICBiZSB0byBndWlkZSBzaW11bGF0aW9ucyB3b3JrLg0KDQozLjMuICBB c3N1bXB0aW9uIDM6IE1hbnkgZmxvd3MgYW5kIGFkZGl0aW9uYWwgbG9hZA0KDQogICBXZSBhc3N1 bWUgdGhhdCB0aGVyZSBhcmUgbWFueSBmbG93cyBvbiBhbnkgYm90dGxlbmVjayBsaW5rIGluIHRo ZQ0KICAgUENOLWRvbWFpbiAob3IsIHRvIHB1dCBpdCBhbm90aGVyIHdheSwgdGhlIGFnZ3JlZ2F0 ZSBiaXQgcmF0ZSBvZiBQQ04tDQogICB0cmFmZmljIGFjcm9zcyBhbnkgcG90ZW50aWFsIGJvdHRs ZW5lY2sgbGluayBpcyBzdWZmaWNpZW50bHkgbGFyZ2UNCiAgIHJlbGF0aXZlIHRvIHRoZSBtYXhp bXVtIGFkZGl0aW9uYWwgYml0IHJhdGUgYWRkZWQgYnkgb25lIGZsb3cpLg0KICAgTWVhc3VyZW1l bnQtYmFzZWQgYWRtaXNzaW9uIGNvbnRyb2wgYXNzdW1lcyB0aGF0IHRoZSBwcmVzZW50IGlzIGEN CiAgIHJlYXNvbmFibGUgcHJlZGljdGlvbiBvZiB0aGUgZnV0dXJlOiB0aGUgbmV0d29yayBjb25k aXRpb25zIGFyZQ0KICAgbWVhc3VyZWQgYXQgdGhlIHRpbWUgb2YgYSBuZXcgZmxvdyByZXF1ZXN0 LCBob3dldmVyIHRoZSBhY3R1YWwNCiAgIG5ldHdvcmsgcGVyZm9ybWFuY2UgbXVzdCBiZSBPSyBk dXJpbmcgdGhlIGNhbGwgc29tZSB0aW1lIGxhdGVyLiAgT25lDQogICBpc3N1ZSBpcyB0aGF0IGlm IHRoZXJlIGFyZSBvbmx5IGEgZmV3IHZhcmlhYmxlIHJhdGUgZmxvd3MsIHRoZW4gdGhlDQogICBh Z2dyZWdhdGUgdHJhZmZpYyBsZXZlbCBtYXkgdmFyeSBhIGxvdCwgcGVyaGFwcyBlbm91Z2ggdG8g Y2F1c2Ugc29tZQ0KICAgcGFja2V0cyB0byBnZXQgZHJvcHBlZC4gIElmIHRoZXJlIGFyZSBtYW55 IGZsb3dzIHRoZW4gdGhlIGFnZ3JlZ2F0ZQ0KICAgdHJhZmZpYyBsZXZlbCBzaG91bGQgYmUgc3Rh dGlzdGljYWxseSBzbW9vdGhlZC4gIEhvdyBtYW55IGZsb3dzIGlzDQogICBlbm91Z2ggZGVwZW5k cyBvbiBhIG51bWJlciBvZiB0aGluZ3Mgc3VjaCBhcyB0aGUgdmFyaWF0aW9uIGluIGVhY2gNCiAg IGZsb3cncyByYXRlLCB0aGUgdG90YWwgcmF0ZSBvZiBQQ04tdHJhZmZpYywgYW5kIHRoZSBzaXpl IG9mIHRoZQ0KICAgInNhZmV0eSBtYXJnaW4iIGJldHdlZW4gdGhlIHRyYWZmaWMgbGV2ZWwgYXQg d2hpY2ggd2Ugc3RhcnQNCiAgIGFkbWlzc2lvbi1tYXJraW5nIGFuZCBhdCB3aGljaCBwYWNrZXRz IGFyZSBkcm9wcGVkLg0KDQogICBXZSBkbyBub3QgbWFrZSBleHBsaWNpdCBhc3N1bXB0aW9ucyBv biBob3cgbWFueSBQQ04tZmxvd3MgYXJlIGluIGVhY2gNCiAgIGluZ3Jlc3MtZWdyZXNzLWFnZ3Jl Z2F0ZS4gIFBlcmZvcm1hbmNlIGV2YWx1YXRpb24gd29yayBtYXkgY2xhcmlmeQ0KICAgd2hldGhl ciBpdCBpcyBuZWNlc3NhcnkgdG8gbWFrZSBhbnkgYWRkaXRpb25hbCBhc3N1bXB0aW9uIG9uDQog ICBhZ2dyZWdhdGlvbiBhdCB0aGUgaW5ncmVzcy1lZ3Jlc3MtYWdncmVnYXRlIGxldmVsLg0KDQoz LjQuICBBc3N1bXB0aW9uIDQ6IEVtZXJnZW5jeSB1c2Ugb3V0IG9mIHNjb3BlDQoNCiAgIFBDTi1m bG93cyBtYXkgaGF2ZSBkaWZmZXJlbnQgcHJlY2VkZW5jZSwgYnV0IHRoZSBhcHBsaWNhYmlsaXR5 IG9mIHRoZQ0KICAgUENOIG1lY2hhbmlzbXMgZm9yIGVtZXJnZW5jeSB1c2UgKDkxMSwgR0VUUywg V1BTLCBNTFBQLCBldGMpIGlzIG91dA0KICAgb2Ygc2NvcGUuDQoNCg0KDQpFYXJkbGV5IChFZGl0 b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDksIDIwMDggICAgICAgICAgICAgICAgW1BhZ2Ug OV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgRG9jdW1lbnQgICAgICAgICAg ICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCjMuNS4gIE90aGVyIGFzc3VtcHRpb25zDQoNCiAg IEl0IGlzIGFzc3VtZWQgdGhhdCBQQ04tbWFya2luZyBpcyBiZWluZyBhcHBsaWVkIHRvIHRyYWZm aWMgc2NoZWR1bGVkDQogICB3aXRoIHRoZSBleHBlZGl0ZWQgZm9yd2FyZGluZyBwZXItaG9wIGJl aGF2aW91ciwgW1JGQzMyNDZdLg0KDQogICBJdCBpcyBhc3N1bWVkIHRoYXQgUENOLW5vZGVzIGRv IG5vdCBwZXJmb3JtIEVDTiwgW1JGQzMyNDZdLCBvbiBQQ04tDQogICBwYWNrZXRzLg0KDQogICBJ ZiBhIHBhY2tldCB0aGF0IGlzIHBhcnQgb2YgYSBQQ04tZmxvdyBhcnJpdmVzIGF0IGEgUENOLWlu Z3Jlc3Mtbm9kZQ0KICAgd2l0aCBpdHMgQ0UgKENvbmdlc3Rpb24gZXhwZXJpZW5jZWQpIGNvZGVw b2ludCBzZXQsIHRoZW4gd2UgYXNzdW1lDQogICB0aGF0IHRoZSBQQ04taW5ncmVzcy1ub2RlIGRy b3BzIHRoZSBwYWNrZXQuICBBZnRlciBpdHMgaW5pdGlhbA0KICAgQ2hhcnRlciBpcyBjb21wbGV0 ZSwgdGhlIFdHIG1heSBkZWNpZGUgdG8gd29yayBvbiBhIG1lY2hhbmlzbSAoc3VjaA0KICAgYXMg dGhyb3VnaCBhIHNpZ25hbGxpbmcgZXh0ZW5zaW9uKSB0aGF0IGVuYWJsZXMgRUNOLW1hcmtpbmcg dG8gYmUNCiAgIGNhcnJpZWQgdHJhbnNwYXJlbnRseSBhY3Jvc3MgdGhlIFBDTi1kb21haW4uDQoN Cg0KNC4gIEhpZ2gtbGV2ZWwgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUNCg0KICAgVGhlIGhpZ2gt bGV2ZWwgYXBwcm9hY2ggaXMgdG8gc3BsaXQgZnVuY3Rpb25hbGl0eSBiZXR3ZWVuOg0KDQogICBv ICBQQ04taW50ZXJpb3Itbm9kZXMgJ2luc2lkZScgdGhlIFBDTi1kb21haW4sIHdoaWNoIG1vbml0 b3IgdGhlaXINCiAgICAgIG93biBzdGF0ZSBvZiBwcmUtY29uZ2VzdGlvbiBhbmQgbWFyayBQQ04t cGFja2V0cyBpZiBhcHByb3ByaWF0ZS4NCiAgICAgIFRoZXkgYXJlIG5vdCBmbG93LWF3YXJlLCBu b3IgYXdhcmUgb2YgaW5ncmVzcy1lZ3Jlc3MtYWdncmVnYXRlcy4NCg0KICAgbyAgUENOLWJvdW5k YXJ5LW5vZGVzIGF0IHRoZSBlZGdlIG9mIHRoZSBQQ04tZG9tYWluLCB3aGljaCBjb250cm9sDQog ICAgICBhZG1pc3Npb24gb2YgbmV3IFBDTi1mbG93cyBhbmQgdGVybWluYXRpb24gb2YgZXhpc3Rp bmcgUENOLWZsb3dzLA0KICAgICAgYmFzZWQgb24gaW5mb3JtYXRpb24gZnJvbSBQQ04taW50ZXJp b3Itbm9kZS4gIFRoaXMgaW5mb3JtYXRpb24gaXMNCiAgICAgIGluIHRoZSBmb3JtIG9mIHRoZSBQ Q04tbWFya2VkIGRhdGEgcGFja2V0cyAod2hpY2ggYXJlIGludGVyY2VwdGVkDQogICAgICBieSB0 aGUgUENOLWVncmVzcy1ub2RlcykgYW5kIG5vdCBzaWduYWxsaW5nIG1lc3NhZ2VzLiAgUENOLQ0K ICAgICAgaW5ncmVzcy1ub2RlcyBhcmUgZmxvdy1hd2FyZSAocmVxdWlyZWQgZm9yIHBvbGljaW5n IHB1cnBvc2VzKS4gIEluDQogICAgICBzZXZlcmFsIGRlcGxveW1lbnQgc2NlbmFyaW9zIFBDTi1l Z3Jlc3Mtbm9kZXMgd2lsbCBhbHNvIGJlIGZsb3cNCiAgICAgIGF3YXJlLiAgKE5vcm1hbGx5IHRo aXMgYWRkcyBubyBjb21wbGV4aXR5IHNpbmNlIGEgUENOLWJvdW5kYXJ5LQ0KICAgICAgbm9kZSBh Y3RzIGFzIGJvdGggYSBQQ04taW5ncmVzcy1ub2RlIGFuZCBhcyBhIFBDTi1lZ3Jlc3Mtbm9kZS4p DQoNCiAgIFRoZSBhaW0gb2YgdGhpcyBzcGxpdCBpcyB0byBrZWVwIHRoZSBidWxrIG9mIHRoZSBu ZXR3b3JrIHNpbXBsZSwNCiAgIHNjYWxhYmxlIGFuZCByb2J1c3QsIHdoaWxzdCBjb25maW5pbmcg cG9saWN5LCBhcHBsaWNhdGlvbi1sZXZlbCBhbmQNCiAgIHNlY3VyaXR5IGludGVyYWN0aW9ucyB0 byB0aGUgZWRnZSBvZiB0aGUgUENOLWRvbWFpbi4gIEZvciBleGFtcGxlIHRoZQ0KICAgbGFjayBv ZiBmbG93IGF3YXJlbmVzcyBtZWFucyB0aGF0IHRoZSBQQ04taW50ZXJpb3Itbm9kZXMgZG9uJ3Qg Y2FyZQ0KICAgYWJvdXQgdGhlIGZsb3cgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBQ Q04tcGFja2V0cyB0aGF0IHRoZXkNCiAgIGNhcnJ5LCBub3IgZG8gdGhlIFBDTi1ib3VuZGFyeS1u b2RlcyBjYXJlIGFib3V0IHdoaWNoIFBDTi1pbnRlcmlvci0NCiAgIG5vZGVzIGl0cyBmbG93cyB0 cmF2ZXJzZS4NCg0KICAgRmxvdyBhZG1pc3Npb246DQoNCiAgIEF0IGEgaGlnaCBsZXZlbCwgZmxv dyBhZG1pc3Npb24gY29udHJvbCB3b3JrcyBhcyBmb2xsb3dzLiAgSW4gb3JkZXINCiAgIHRvIGdl bmVyYXRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBQQ04tZG9t YWluLA0KICAgZWFjaCBQQ04tbm9kZSBQQ04tbWFya3MgcGFja2V0cyBpZiBpdCBpcyAicHJlLWNv bmdlc3RlZCIuICBFeGFjdGx5DQogICBob3cgYSBQQ04tbm9kZSBkZWNpZGVzIGlmIGl0IGlzICJw cmUtY29uZ2VzdGVkIiAodGhlIGFsZ29yaXRobSkgYW5kDQoNCg0KDQpFYXJkbGV5IChFZGl0b3Ip ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDksIDIwMDggICAgICAgICAgICAgICBbUGFnZSAxMF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgRG9jdW1lbnQgICAgICAgICAgICAg ICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIGV4YWN0bHkgaG93IHBhY2tldHMgYXJlICJQQ04t bWFya2VkIiAodGhlIGVuY29kaW5nKSB3aWxsIGJlIGRlZmluZWQNCiAgIGluIGEgc2VwYXJhdGUg c3RhbmRhcmRzLXRyYWNrIGRvY3VtZW50LCBidXQgYXQgYSBoaWdoIGxldmVsIGl0IGlzDQogICBl eHBlY3RlZCB0byBiZSBhcyBmb2xsb3dzOg0KDQogICBvICB0aGUgYWxnb3JpdGhtOiBhIFBDTi1u b2RlIG1ldGVycyB0aGUgYW1vdW50IG9mIFBDTi10cmFmZmljIG9uIGVhY2gNCiAgICAgIG9uZSBv ZiBpdHMgb3V0Z29pbmcgbGlua3MuICBUaGUgbWVhc3VyZW1lbnQgaXMgbWFkZSBhcyBhbg0KICAg ICAgYWdncmVnYXRlIG9mIGFsbCBQQ04tcGFja2V0cywgYW5kIG5vdCBwZXIgZmxvdy4gIFRoZSBh bGdvcml0aG0gaGFzDQogICAgICBhIGNvbmZpZ3VyZWQgcGFyYW1ldGVyLCBQQ04tbG93ZXItcmF0 ZS4gIEFzIHRoZSBhbW91bnQgb2YgUENOLQ0KICAgICAgdHJhZmZpYyBleGNlZWRzIHRoZSBQQ04t bG93ZXItcmF0ZSwgdGhlbiBQQ04tcGFja2V0cyBhcmUgUENOLQ0KICAgICAgbWFya2VkLiAgU2Vl IE5PVEUgYmVsb3cgZm9yIG1vcmUgZXhwbGFuYXRpb24uDQoNCiAgIG8gIHRoZSBlbmNvZGluZzog YSBQQ04tbm9kZSBQQ04tbWFya3MgYSBQQ04tcGFja2V0ICh3aXRoIGEgZmlyc3QNCiAgICAgIGVu Y29kaW5nKSBieSBzZXR0aW5nIGZpZWxkcyBpbiB0aGUgaGVhZGVyIHRvIHNwZWNpZmljIHZhbHVl cy4gIEl0DQogICAgICBpcyBleHBlY3RlZCB0aGF0IHRoZSBFQ04gYW5kL29yIERTQ1AgZmllbGRz IHdpbGwgYmUgdXNlZC4NCg0KICAgTk9URTogVHdvIG1haW4gY2F0ZWdvcmllcyBvZiBhbGdvcml0 aG0gaGF2ZSBiZWVuIHByb3Bvc2VkOiBpZiB0aGUNCiAgIGFsZ29yaXRobSB1c2VzIHRocmVzaG9s ZC1tYXJraW5nIHRoZW4gYWxsIFBDTi1wYWNrZXRzIGFyZSBtYXJrZWQgaWYNCiAgIHRoZSBjdXJy ZW50IHJhdGUgZXhjZWVkcyB0aGUgUENOLWxvd2VyLXJhdGUsIHdoZXJlYXMgaWYgdGhlIGFsZ29y aXRobQ0KICAgdXNlcyBleGNlc3MtcmF0ZS1tYXJraW5nIHRoZSBhbW91bnQgbWFya2VkIGlzIGVx dWFsIHRvIHRoZSBhbW91bnQgaW4NCiAgIGV4Y2VzcyBvZiB0aGUgUENOLWxvd2VyLXJhdGUuICBI b3dldmVyLCBub3RlIHRoYXQgdGhpcyBkZXNjcmlwdGlvbg0KICAgcmVmbGVjdHMgdGhlIG92ZXJh bGwgaW50ZW50IG9mIHRoZSBhbGdvcml0aG0gcmF0aGVyIHRoYW4gaXRzDQogICBpbnN0YW50YW5l b3VzIGJlaGF2aW91ciwgc2luY2UgdGhlIHJhdGUgbWVhc3VyZWQgYXQgYSBwYXJ0aWN1bGFyDQog ICBtb21lbnQgZGVwZW5kcyBvbiB0aGUgZGV0YWlsZWQgYWxnb3JpdGhtLCBpdHMgaW1wbGVtZW50 YXRpb24gKGVnDQogICB2aXJ0dWFsIHF1ZXVlLCB0b2tlbiBidWNrZXQuLi4pIGFuZCB0aGUgdHJh ZmZpYydzIHZhcmlhbmNlIGFzIHdlbGwgYXMNCiAgIGl0cyByYXRlIChlZyBtYXJraW5nIG1heSB3 ZWxsIGNvbnRpbnVlIGFmdGVyIGEgcmVjZW50IG92ZXJsb2FkIGV2ZW4NCiAgIGFmdGVyIHRoZSBp bnN0YW50YW5lb3VzIHJhdGUgaGFzIGRyb3BwZWQpLg0KDQogICBUaGUgUENOLWJvdW5kYXJ5LW5v ZGVzIG1vbml0b3IgdGhlIFBDTi1tYXJrZWQgcGFja2V0cyBpbiBvcmRlciB0bw0KICAgZXh0cmFj dCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgUENOLWRvbWFpbi4g IEJhc2VkDQogICBvbiB0aGlzIG1vbml0b3JpbmcsIGEgZGVjaXNpb24gaXMgbWFkZSBhYm91dCB3 aGV0aGVyIHRvIGFkbWl0IGENCiAgIHByb3NwZWN0aXZlIG5ldyBmbG93LiAgRXhhY3RseSBob3cg dGhlIGFkbWlzc2lvbiBjb250cm9sIGRlY2lzaW9uIGlzDQogICBtYWRlIHdpbGwgYmUgZGVmaW5l ZCBpbiBzZXBhcmF0ZWx5IChhdCB0aGUgbW9tZW50IHRoZSBpbnRlbnRpb24gaXMNCiAgIHRoYXQg dGhlcmUgd2lsbCBiZSBvbmUgb3IgbW9yZSBpbmZvcm1hdGlvbmFsLXRyYWNrIFJGQ3MpLCBidXQg YXQgYQ0KICAgaGlnaCBsZXZlbCBpdCBpcyBleHBlY3RlZCB0byBiZSBhcyBmb2xsb3dzOg0KDQog ICBvICB0aGUgUENOLWVncmVzcy1ub2RlIG1lYXN1cmVzIChwb3NzaWJseSBhcyBhIG1vdmluZyBh dmVyYWdlKSB0aGUNCiAgICAgIGZyYWN0aW9uIG9mIHRoZSBQQ04tdHJhZmZpYyB0aGF0IGlzIFBD Ti1tYXJrZWQuICBUaGUgZnJhY3Rpb24gaXMNCiAgICAgIG1lYXN1cmVkIGZvciBhIHNwZWNpZmlj IGluZ3Jlc3MtZWdyZXNzLWFnZ3JlZ2F0ZS4gIElmIHRoZSBmcmFjdGlvbg0KICAgICAgaXMgYmVs b3cgYSB0aHJlc2hvbGQgdmFsdWUgdGhlbiB0aGUgbmV3IGZsb3cgaXMgYWRtaXR0ZWQuDQoNCiAg IE5vdGUgdGhhdCB0aGUgUENOLWxvd2VyLXJhdGUgaXMgYSBwYXJhbWV0ZXIgdGhhdCBjYW4gYmUg Y29uZmlndXJlZCBieQ0KICAgdGhlIG9wZXJhdG9yLiAgSXQgd2lsbCBiZSBzZXQgbG93ZXIgdGhh biB0aGUgdHJhZmZpYyByYXRlIGF0IHdoaWNoDQogICB0aGUgbGluayBiZWNvbWVzIGNvbmdlc3Rl ZCBhbmQgdGhlIG5vZGUgZHJvcHMgcGFja2V0cy4gIChIZW5jZSwgYnkNCiAgIGFuYWxvZ3kgd2l0 aCBFQ04gd2UgY2FsbCBvdXIgbWVjaGFuaXNtIFByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbi4p DQoNCiAgIE5vdGUgYWxzbyB0aGF0IHRoZSBhZG1pc3Npb24gY29udHJvbCBkZWNpc2lvbiBpcyBt YWRlIGZvciBhDQogICBwYXJ0aWN1bGFyIGluZ3Jlc3MtZWdyZXNzLWFnZ3JlZ2F0ZS4gIFNvIGl0 IGlzIHF1aXRlIHBvc3NpYmxlIGZvciBhDQogICBuZXcgZmxvdyB0byBiZSBhZG1pdHRlZCBiZXR3 ZWVuIG9uZSBwYWlyIG9mIFBDTi1ib3VuZGFyeS1ub2RlcywNCg0KDQoNCkVhcmRsZXkgKEVkaXRv cikgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDEx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgd2hpbHN0IGF0IHRoZSBzYW1lIHRpbWUgYW5v dGhlciBhZG1pc3Npb24gcmVxdWVzdCBpcyBibG9ja2VkIGJldHdlZW4NCiAgIGEgZGlmZmVyZW50 IHBhaXIgb2YgUENOLWJvdW5kYXJ5LW5vZGVzLg0KDQogICBGbG93IHRlcm1pbmF0aW9uOg0KDQog ICBBdCBhIGhpZ2ggbGV2ZWwsIGZsb3cgdGVybWluYXRpb24gY29udHJvbCB3b3JrcyBhcyBmb2xs b3dzLiAgRWFjaA0KICAgUENOLW5vZGUgUENOLW1hcmtzIHBhY2tldHMgaW4gYSBzaW1pbGFyIGZh c2hpb24gdG8gYWJvdmUuICBBbiBvYnZpb3VzDQogICBhcHByb2FjaCBpcyBmb3IgdGhlIGFsZ29y aXRobSB0byB1c2UgYSBzZWNvbmQgY29uZmlndXJlZCBwYXJhbWV0ZXIsDQogICBQQ04tdXBwZXIt cmF0ZSwgYW5kIGEgc2Vjb25kIGhlYWRlciBlbmNvZGluZyAoIlBDTi11cHBlci1yYXRlLQ0KICAg bWFya2luZyIpLiAgSG93ZXZlciB0aGVyZSBpcyBhbHNvIGEgcHJvcG9zYWwgdG8gdXNlIHRoZSBz YW1lIHJhdGUgYW5kDQogICB0aGUgc2FtZSBlbmNvZGluZy4gIFNldmVyYWwgYXBwcm9hY2hlcyBo YXZlIGJlZW4gcHJvcG9zZWQgdG8gZGF0ZQ0KICAgYWJvdXQgaG93IHRvIGNvbnZlcnQgdGhpcyBp bmZvcm1hdGlvbiBpbnRvIGEgZmxvdyB0ZXJtaW5hdGlvbg0KICAgZGVjaXNpb247IGF0IGEgaGln aCBsZXZlbCB0aGVzZSBhcmUgYXMgZm9sbG93czoNCg0KICAgbyAgT25lIGFwcHJvYWNoIG1lYXN1 cmVzIHRoZSByYXRlIG9mIHVubWFya2VkIFBDTi10cmFmZmljIChpZSBub3QNCiAgICAgIFBDTi11 cHBlci1yYXRlLW1hcmtlZCkgYXQgdGhlIFBDTi1lZ3Jlc3Mtbm9kZSwgd2hpY2ggaXMgdGhlIGFt b3VudA0KICAgICAgb2YgUENOLXRyYWZmaWMgdGhhdCBjYW4gYWN0dWFsbHkgYmUgc3VwcG9ydGVk OyB0aGUgUENOLWluZ3Jlc3MtDQogICAgICBub2RlIG1lYXN1cmVzIHRoZSByYXRlIG9mIFBDTi10 cmFmZmljIHRoYXQgaXMgZGVzdGluZWQgZm9yIHRoaXMNCiAgICAgIHNwZWNpZmljIFBDTi1lZ3Jl c3Mtbm9kZSwgYW5kIGhlbmNlIGNhbiBjYWxjdWxhdGUgdGhlIGV4Y2Vzcw0KICAgICAgYW1vdW50 IHRoYXQgc2hvdWxkIGJlIHRlcm1pbmF0ZWQuDQoNCiAgIG8gIEFub3RoZXIgYXBwcm9hY2ggaW5z dGVhZCBtZWFzdXJlcyB0aGUgcmF0ZSBvZiBQQ04tdXBwZXItcmF0ZS0NCiAgICAgIG1hcmtlZCB0 cmFmZmljIGFuZCBjYWxjdWxhdGVzIGFuZCBzZWxlY3RzIHRoZSBmbG93cyB0aGF0IHNob3VsZCBi ZQ0KICAgICAgdGVybWluYXRlZC4NCg0KICAgbyAgQW5vdGhlciBhcHByb2FjaCB0ZXJtaW5hdGVz IGFueSBQQ04tZmxvdyB3aXRoIGEgUENOLXVwcGVyLXJhdGUtDQogICAgICBtYXJrZWQgcGFja2V0 LiAgSXQgbmVlZHMgYSBkaWZmZXJlbnQgbWFya2luZyBhbGdvcml0aG0sIG90aGVyd2lzZQ0KICAg ICAgZmFyIHRvbyBtdWNoIHRyYWZmaWMgd291bGQgYmUgdGVybWluYXRlZC4NCg0KICAgbyAgQW5v dGhlciBhcHByb2FjaCB1c2VzIG9ubHkgb25lIHNvcnQgb2YgbWFya2luZywgd2hpY2ggaXMgYmFz ZWQgb24NCiAgICAgIHRoZSBQQ04tbG93ZXItcmF0ZSwgdG8gZGVjaWRlIG5vdCBvbmx5IHdoZXRo ZXIgdG8gYWRtaXQgbW9yZSBQQ04tDQogICAgICBmbG93cyBidXQgYWxzbyB3aGV0aGVyIGFueSBQ Q04tZmxvd3MgbmVlZCB0byBiZSB0ZXJtaW5hdGVkLiAgSXQNCiAgICAgIGFzc3VtZXMgdGhhdCB0 aGUgcmF0aW8gb2YgdGhlIChpbXBsaWNpdCkgUENOLXVwcGVyLXJhdGUgYW5kIHRoZQ0KICAgICAg UENOLWxvd2VyLXJhdGUgaXMgdGhlIHNhbWUgb24gYWxsIGxpbmtzLiAgVGhpcyBhcHByb2FjaCBt ZWFzdXJlcw0KICAgICAgdGhlIHJhdGUgb2YgdW5tYXJrZWQgUENOLXRyYWZmaWMgYXQgYSBQQ04t ZWdyZXNzLW5vZGUuICBUaGUgUENOLQ0KICAgICAgaW5ncmVzcy1ub2RlIHVzZXMgdGhpcyBtZWFz dXJlbWVudCB0byBjb21wdXRlIHRoZSBpbXBsaWNpdCBQQ04tDQogICAgICB1cHBlci1yYXRlIG9m IHRoZSBib3R0bGVuZWNrIGxpbmsuICBJdCB0aGVuIG1lYXN1cmVzIHRoZSByYXRlIG9mDQogICAg ICBQQ04tdHJhZmZpYyB0aGF0IGlzIGRlc3RpbmVkIGZvciB0aGlzIHNwZWNpZmljIFBDTi1lZ3Jl c3Mtbm9kZSBhbmQNCiAgICAgIGhlbmNlIGNhbiBjYWxjdWxhdGUgdGhlIGFtb3VudCB0aGF0IHNo b3VsZCBiZSB0ZXJtaW5hdGVkLg0KDQogICBTaW5jZSBmbG93IHRlcm1pbmF0aW9uIGlzIGRlc2ln bmVkIGZvciAiYWJub3JtYWwiIGNpcmN1bXN0YW5jZXMsIGl0DQogICBpcyBxdWl0ZSBsaWtlbHkg dGhhdCBzb21lIFBDTi1ub2RlcyBhcmUgY29uZ2VzdGVkIGFuZCBoZW5jZSBwYWNrZXRzDQogICBh cmUgYmVpbmcgZHJvcHBlZCBhbmQvb3Igc2lnbmlmaWNhbnRseSBxdWV1ZWQuICBUaGUgZmxvdyB0 ZXJtaW5hdGlvbg0KICAgbWVjaGFuaXNtIG11c3QgYmVhciB0aGlzIGluIG1pbmQuDQoNCiAgIE5v dGUgYWxzbyB0aGF0IHRoZSB0ZXJtaW5hdGlvbiBjb250cm9sIGRlY2lzaW9uIGlzIG1hZGUgZm9y IGENCiAgIHBhcnRpY3VsYXIgaW5ncmVzcy1lZ3Jlc3MtYWdncmVnYXRlLiAgU28gaXQgaXMgcXVp dGUgcG9zc2libGUgZm9yDQogICBQQ04tZmxvd3MgdG8gYmUgdGVybWluYXRlZCBiZXR3ZWVuIG9u ZSBwYWlyIG9mIFBDTi1ib3VuZGFyeS1ub2RlcywNCg0KDQoNCkVhcmRsZXkgKEVkaXRvcikgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgd2hpbHN0IGF0IHRoZSBzYW1lIHRpbWUgbm9uZSBhcmUg dGVybWluYXRlZCBiZXR3ZWVuIGEgZGlmZmVyZW50IHBhaXINCiAgIG9mIFBDTi1ib3VuZGFyeS1u b2Rlcy4NCg0KICAgQWx0aG91Z2ggZGVzaWduZWQgdG8gd29yayB0b2dldGhlciwgZmxvdyBhZG1p c3Npb24gYW5kIGZsb3cNCiAgIHRlcm1pbmF0aW9uIGFyZSBpbmRlcGVuZGVudCBtZWNoYW5pc21z LCBhbmQgdGhlIHVzZSBvZiBvbmUgZG9lcyBub3QNCiAgIHJlcXVpcmUgb3IgcHJldmVudCB0aGUg dXNlIG9mIHRoZSBvdGhlciAoZGlzY3Vzc2VkIGZ1cnRoZXIgaW4gU2VjdGlvbg0KICAgNy4yKS4N Cg0KICAgSW5mb3JtYXRpb24gdHJhbnNwb3J0Og0KDQogICBUaGUgdHJhbnNwb3J0IG9mIHByZS1j b25nZXN0aW9uIGluZm9ybWF0aW9uIGZyb20gYSBQQ04tbm9kZSB0byBhIFBDTi0NCiAgIGVncmVz cy1ub2RlIGlzIHRocm91Z2ggUENOLW1hcmtpbmdzIGluIGRhdGEgcGFja2V0IGhlYWRlcnMsIG5v DQogICBzaWduYWxsaW5nIHByb3RvY29sIG1lc3NhZ2luZyBpcyBuZWVkZWQuICBIb3dldmVyLCBz aWduYWxsaW5nIGlzDQogICBuZWVkZWQgdG8gdHJhbnNwb3J0IFBDTi1mZWVkYmFjay1pbmZvcm1h dGlvbiBiZXR3ZWVuIHRoZSBQQ04tDQogICBib3VuZGFyeS1ub2RlcywgZm9yIGV4YW1wbGUgdG8g Y29udmV5IHRoZSBmcmFjdGlvbiBvZiBQQ04tbWFya2VkDQogICB0cmFmZmljIGZyb20gYSBQQ04t ZWdyZXNzLW5vZGUgdG8gdGhlIHJlbGV2YW50IFBDTi1pbmdyZXNzLW5vZGUuDQogICBFeGFjdGx5 IHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgdHJhbnNwb3J0ZWQgd2lsbCBiZSBkZXNjcmli ZWQgaW4NCiAgIHRoZSBmdXR1cmUgUENOIFdHIGRvY3VtZW50KHMpIGFib3V0IHRoZSBib3VuZGFy eSBtZWNoYW5pc21zLiAgVGhlDQogICBzaWduYWxsaW5nIGNvdWxkIGJlIGRvbmUgYnkgYW4gZXh0 ZW5zaW9uIG9mIFJTVlAgb3IgTlNJUywgZm9yDQogICBpbnN0YW5jZTsgcHJvdG9jb2wgd29yayB3 aWxsIGJlIGRvbmUgYnkgdGhlIHJlbGV2YW50IFdHLCBidXQgZm9yDQogICBleGFtcGxlIFtJLUQu bGVmYXVjaGV1ci1yc3ZwLWVjbl1kZXNjcmliZXMgdGhlIGV4dGVuc2lvbnMgbmVlZGVkIGZvcg0K ICAgUlNWUC4NCg0KICAgVGhlIGZvbGxvd2luZyBhcmUgc29tZSBoaWdoLWxldmVsIHBvaW50cyBh Ym91dCBob3cgUENOIHdvcmtzOg0KDQogICBvICBUaGVyZSBuZWVkcyB0byBiZSBhIHdheSBmb3Ig YSBQQ04tbm9kZSB0byBkaXN0aW5ndWlzaCBQQ04tdHJhZmZpYw0KICAgICAgZnJvbSBub24gUENO LXRyYWZmaWMuICBUaGV5IG1heSBiZSBkaXN0aW5ndWlzaGVkIHVzaW5nIHRoZSBEU0NQDQogICAg ICBmaWVsZCBhbmQvb3IgRUNOIGZpZWxkLiAgW0ktRC5jaGFuLXBjbi1lbmNvZGluZy1jb21wYXJp c29uXQ0KICAgICAgZGlzY3Vzc2VzIGZ1cnRoZXIuDQoNCiAgIG8gIFRoZSBQQ04gbWVjaGFuaXNt cyBtYXkgYmUgYXBwbGllZCB0byBtb3JlIHRoYW4gb25lIHRyYWZmaWMgY2xhc3MNCiAgICAgICh3 aGljaCBhcmUgZGlzdGluZ3Vpc2hlZCBieSBEU0NQKS4NCg0KICAgbyAgVGhlcmUgbWF5IGJlIHRy YWZmaWMgdGhhdCBpcyBtb3JlIGltcG9ydGFudCB0aGFuIFBDTiwgcGVyaGFwcyBhDQogICAgICBw YXJ0aWN1bGFyIGFwcGxpY2F0aW9uIG9yIGFuIG9wZXJhdG9yJ3MgY29udHJvbCBtZXNzYWdlcy4g IEEgUENOLQ0KICAgICAgbm9kZSBtYXkgZGVkaWNhdGUgY2FwYWNpdHkgdG8gc3VjaCB0cmFmZmlj IG9yIHByaW9yaXR5IHNjaGVkdWxlIGl0DQogICAgICBvdmVyIFBDTi4gIEluIHRoZSBsYXR0ZXIg Y2FzZSBpdHMgdHJhZmZpYyBuZWVkcyB0byBjb250cmlidXRlIHRvDQogICAgICB0aGUgUENOIG1l dGVycy4NCg0KICAgbyAgVGhlcmUgd2lsbCBiZSB0cmFmZmljIGxlc3MgaW1wb3J0YW50IHRoYW4g UENOLiAgRm9yIGluc3RhbmNlIGJlc3QNCiAgICAgIGVmZm9ydCBvciBhc3N1cmVkIGZvcndhcmRp bmcgdHJhZmZpYy4gIEl0IHdpbGwgYmUgc2NoZWR1bGVkIGF0DQogICAgICBsb3dlciBwcmlvcml0 eSB0aGFuIFBDTiwgYW5kIHVzZSBhIHNlcGFyYXRlIHF1ZXVlIG9yIHF1ZXVlcy4NCiAgICAgIEhv d2V2ZXIsIGEgUENOLW5vZGUgbWF5IGRlZGljYXRlIHNvbWUgY2FwYWNpdHkgdG8gbG93ZXIgcHJp b3JpdHkNCiAgICAgIHRyYWZmaWMgc28gdGhhdCBpdCBpc24ndCBzdGFydmVkLg0KDQogICBvICBU aGVyZSBtYXkgYmUgb3RoZXIgdHJhZmZpYyB3aXRoIHRoZSBzYW1lIHByaW9yaXR5IGFzIFBDTi10 cmFmZmljLg0KICAgICAgRm9yIGluc3RhbmNlLCBFeHBlZGl0ZWQgRm9yd2FyZGluZyBzZXNzaW9u cyB0aGF0IGFyZSBvcmlnaW5hdGVkDQogICAgICBlaXRoZXIgd2l0aG91dCBjYXBhY2l0eSBhZG1p c3Npb24gb3Igd2l0aCB0cmFmZmljIGVuZ2luZWVyaW5nLiAgSW4NCg0KDQoNCkVhcmRsZXkgKEVk aXRvcikgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdl IDEzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgICAgW0ktRC5pZXRmLXRzdndnLWFkbWl0 dGVkLXJlYWx0aW1lLWRzY3BdIHRoZSB0d28gdHJhZmZpYyBjbGFzc2VzDQogICAgICBhcmUgY2Fs bGVkIEVGIGFuZCBFRi1BRE1JVC4gIEEgUENOLW5vZGUgY291bGQgZWl0aGVyIHVzZSBzZXBhcmF0 ZQ0KICAgICAgcXVldWVzLCBvciBzZXBhcmF0ZSBwb2xpY2VycyBhbmQgYSBjb21tb24gcXVldWU7 IHRoZSBkcmFmdA0KICAgICAgcHJvdmlkZXMgc29tZSBndWlkYW5jZSB3aGVuIGVhY2ggaXMgYmV0 dGVyLCBidXQgZm9yIGluc3RhbmNlIHRoZQ0KICAgICAgbGF0dGVyIGlzIHByZWZlcnJlZCB3aGVu IHRoZSB0d28gdHJhZmZpYyBjbGFzc2VzIGFyZSBjYXJyeWluZyB0aGUNCiAgICAgIHNhbWUgdHlw ZSBvZiBhcHBsaWNhdGlvbiB3aXRoIHRoZSBzYW1lIGppdHRlciByZXF1aXJlbWVudHMuDQoNCg0K NS4gIERldGFpbGVkIEZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlDQoNCiAgIFRoaXMgc2VjdGlvbiBp cyBpbnRlbmRlZCB0byBwcm92aWRlIGEgc3lzdGVtYXRpYyBzdW1tYXJ5IG9mIHRoZSBuZXcNCiAg IGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlIGluIHRoZSBQQ04tZG9tYWluLCB3aGljaCBtYXBzIHRv IHRoZQ0KICAgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkIGJ5IHRoZSBQQ04tbm9k ZXMsIGluIGFkZGl0aW9uIHRvDQogICB0aGVpciBub3JtYWwgcm91dGVyIGZ1bmN0aW9ucy4gIFRo ZSBzZWN0aW9uIGRpc2N1c3NlcyB0aGUNCiAgIGZ1bmN0aW9uYWxpdHkgbmVlZGVkIGZvciBib3Ro IGZsb3cgYWRtaXNzaW9uIGNvbnRyb2wgYW5kIGZsb3cNCiAgIHRlcm1pbmF0aW9uLiAgSXQgaXMg c3BsaXQgaW50bzoNCg0KICAgMS4gIGZ1bmN0aW9ucyBuZWVkZWQgYXQgUENOLWludGVyaW9yLW5v ZGVzDQoNCiAgIDIuICBmdW5jdGlvbnMgbmVlZGVkIGF0IFBDTi1pbmdyZXNzLW5vZGVzDQoNCiAg IDMuICBmdW5jdGlvbnMgbmVlZGVkIGF0IFBDTi1lZ3Jlc3Mtbm9kZXMNCg0KICAgNC4gIG90aGVy IGZ1bmN0aW9ucyBuZWVkZWQgZm9yIGZsb3cgYWRtaXNzaW9uIGNvbnRyb2wNCg0KICAgNS4gIG90 aGVyIGZ1bmN0aW9ucyBuZWVkZWQgZm9yIHByb2JpbmcgKHdoaWNoIG1heSBiZSBuZWVkZWQNCiAg ICAgICBzb21ldGltZXMpDQoNCiAgIDYuICBvdGhlciBmdW5jdGlvbnMgbmVlZGVkIGZvciBmbG93 IHRlcm1pbmF0aW9uIGNvbnRyb2wNCg0KICAgVGhlIHNlY3Rpb24gdGhlbiBkaXNjdXNzZXMgc29t ZSBvdGhlciBkZXRhaWxlZCB0b3BpY3M6DQoNCiAgIDEuICBhZGRyZXNzaW5nDQoNCiAgIDIuICB0 dW5uZWxsaW5nDQoNCiAgIDMuICBmYXVsdCBoYW5kbGluZw0KDQo1LjEuICBQQ04taW50ZXJpb3It bm9kZSBmdW5jdGlvbnMNCg0KICAgRWFjaCBsaW5rIG9mIHRoZSBQQ04tZG9tYWluIGlzIHVwZ3Jh ZGVkIHdpdGggdGhlIGZvbGxvd2luZw0KICAgZnVuY3Rpb25hbGl0eToNCg0KICAgbyAgUGFja2V0 IGNsYXNzaWZ5IC0gZGVjaWRlIHdoZXRoZXIgYW4gaW5jb21pbmcgcGFja2V0IGlzIGEgUENOLQ0K ICAgICAgcGFja2V0IG9yIG5vdC4gIEFub3RoZXIgUENOIFdHIGRvY3VtZW50IHdpbGwgc3BlY2lm eSBlbmNvZGluZywNCiAgICAgIHVzaW5nIHRoZSBEU0NQYW5kL29yIEVDTiBmaWVsZHMuDQoNCg0K DQoNCg0KRWFyZGxleSAoRWRpdG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAg ICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg IERvY3VtZW50ICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBvICBQQ04t bWV0ZXIgLSBtZWFzdXJlIHRoZSAnYW1vdW50IG9mIFBDTi10cmFmZmljJy4gIFRoZSBtZWFzdXJl bWVudA0KICAgICAgaXMgbWFkZSBhcyBhbiBhZ2dyZWdhdGUgb2YgYWxsIFBDTi1wYWNrZXRzLCBh bmQgbm90IHBlciBmbG93Lg0KDQogICBvICBQQ04tbWFyayAtIGFsZ29yaXRobXMgZGV0ZXJtaW5l IHdoZXRoZXIgdG8gUENOLW1hcmsgUENOLXBhY2tldHMNCiAgICAgIGFuZCB3aGF0IHBhY2tldCBl bmNvZGluZyBpcyB1c2VkIChhcyBzcGVjaWZpZWQgaW4gYW5vdGhlciBQQ04gV0cNCiAgICAgIGRv Y3VtZW50KS4NCg0KICAgVGhlIHNhbWUgZ2VuZXJhbCBhcHByb2FjaCBvZiBtZXRlcmluZyBhbmQg UENOLW1hcmtpbmcgaXMgcGVyZm9ybWVkDQogICBmb3IgYm90aCBmbG93IGFkbWlzc2lvbiBjb250 cm9sIGFuZCBmbG93IHRlcm1pbmF0aW9uLCBob3dldmVyIHRoZQ0KICAgYWxnb3JpdGhtcyBhbmQg ZW5jb2RpbmcgbWF5IGJlIGRpZmZlcmVudC4NCg0KICAgVGhlc2UgZnVuY3Rpb25zIGFyZSBuZWVk ZWQgZm9yIGVhY2ggbGluayBvZiB0aGUgUENOLXJlZ2lvbi4gIFRoZXkgYXJlDQogICB0aGVyZWZv cmUgbmVlZGVkIG9uIGFsbCBsaW5rcyBvZiBQQ04taW50ZXJpb3Itbm9kZXMsIGFuZCBvbiB0aGUg bGlua3MNCiAgIG9mIFBDTi1ib3VuZGFyeS1ub2RlcyB0aGF0IGFyZSBpbnRlcm5hbCB0byB0aGUg UENOLWRvbWFpbi4gIFRoZXJlIG1heQ0KICAgYmUgbW9yZSB0aGFuIG9uZSBQQ04tbWV0ZXIgYW5k IG1hcmtlciBpbnN0YWxsZWQgYXQgYSBnaXZlbiBsaW5rLCBlZw0KICAgb25lIGZvciBhZG1pc3Np b24gYW5kIG9uZSBmb3IgdGVybWluYXRpb24uDQoNCjUuMi4gIFBDTi1pbmdyZXNzLW5vZGUgZnVu Y3Rpb25zDQoNCiAgIEVhY2ggaW5ncmVzcyBsaW5rIG9mIHRoZSBQQ04tZG9tYWluIGlzIHVwZ3Jh ZGVkIHdpdGggdGhlIGZvbGxvd2luZw0KICAgZnVuY3Rpb25hbGl0eToNCg0KICAgbyAgUGFja2V0 IGNsYXNzaWZ5IC0gZGVjaWRlIHdoZXRoZXIgYW4gaW5jb21pbmcgcGFja2V0IGlzIHBhcnQgb2Yg YQ0KICAgICAgcHJldmlvdXNseSBhZG1pdHRlZCBtaWNyb2Zsb3csIGJ5IHVzaW5nIGEgZmlsdGVy IHNwZWMgKGVnIERTQ1AsDQogICAgICBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBh bmQgcG9ydCBudW1iZXJzKQ0KDQogICBvICBQb2xpY2UgLSBwb2xpY2UsIGJ5IGRyb3BwaW5nIG9y IHJlLW1hcmtpbmcgd2l0aCBhIG5vbi1QQ04gRFNDUCwNCiAgICAgIGFueSBwYWNrZXRzIHJlY2Vp dmVkIHdpdGggYSBEU0NQIGRlbWFuZGluZyBQQ04gdHJhbnNwb3J0IHRoYXQgZG8NCiAgICAgIG5v dCBiZWxvbmcgdG8gYW4gYWRtaXR0ZWQgZmxvdy4gIFNpbWlsYXJseSwgcG9saWNlIHBhY2tldHMg dGhhdA0KICAgICAgYXJlIHBhcnQgb2YgYSBwcmV2aW91c2x5IGFkbWl0dGVkIG1pY3JvZmxvdywg dG8gY2hlY2sgdGhhdCB0aGUNCiAgICAgIG1pY3JvZmxvdyBrZWVwcyB0byB0aGUgYWdyZWVkIHJh dGUgb3IgZmxvd3NwZWMgKGVnIFJGQzE2MzMNCiAgICAgIFtSRkMxNjMzXSBhbmQgTlNJUyBlcXVp dmFsZW50KS4NCg0KICAgbyAgUENOLWNvbG91ciAtIHNldCB0aGUgRFNDUCBmaWVsZCBvciBEU0NQ IGFuZCBFQ04gZmllbGRzIHRvIHRoZQ0KICAgICAgYXBwcm9wcmlhdGUgdmFsdWUocykgZm9yIGEg UENOLXBhY2tldC4gIFRoZSBkcmFmdCBhYm91dCBQQ04tDQogICAgICBlbmNvZGluZyB3aWxsIGRp c2N1c3MgZnVydGhlci4NCg0KICAgbyAgUENOLW1ldGVyIC0gbWFrZSAibWVhc3VyZW1lbnRzIG9m IFBDTi10cmFmZmljIi4gIFNvbWUgYXBwcm9hY2hlcw0KICAgICAgdG8gZmxvdyB0ZXJtaW5hdGlv biByZXF1aXJlIHRoZSBQQ04taW5ncmVzcy1ub2RlIHRvIG1lYXN1cmUgdGhlDQogICAgICAoYWdn cmVnYXRlKSByYXRlIG9mIFBDTi10cmFmZmljIHRvd2FyZHMgYSBwYXJ0aWN1bGFyIFBDTi1lZ3Jl c3MtDQogICAgICBub2RlLg0KDQogICBUaGUgZmlyc3QgdHdvIGFyZSBwb2xpY2luZyBmdW5jdGlv bnMsIG5lZWRlZCB0byBtYWtlIHN1cmUgdGhhdCBQQ04tDQogICBwYWNrZXRzIGxldCBpbnRvIHRo ZSBQQ04tZG9tYWluIGJlbG9uZyB0byBhIGZsb3cgdGhhdCdzIGJlZW4gYWRtaXR0ZWQNCiAgIChh bmQgcHJvYmFibHkgYWxzbyB0byBlbnN1cmUgdGhhdCB0aGUgZmxvdyBkb2Vzbid0IGdvIGF0IGEg ZmFzdGVyDQogICByYXRlIHRoYW4gYWxsb3dlZCBieSBpdHMgc2VydmljZSBsZXZlbCBhZ3JlZW1l bnQpLiAgVGhlIGZpbHRlciBzcGVjDQogICB3aWxsIGZvciBleGFtcGxlIGNvbWUgZnJvbSB0aGUg ZmxvdyByZXF1ZXN0IG1lc3NhZ2UgKG91dHNpZGUgc2NvcGUgb2YNCiAgIFBDTiBXRywgc2VlIFtJ LUQuYnJpc2NvZS10c3Z3Zy1jbC1hcmNoaXRlY3R1cmVdIGZvciBhbiBleGFtcGxlIHVzaW5nDQoN Cg0KDQpFYXJkbGV5IChFZGl0b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDksIDIwMDggICAg ICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg RG9jdW1lbnQgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIFJTVlApLiAg UENOLWNvbG91cmluZyBhbGxvd3MgdGhlIHJlc3Qgb2YgdGhlIFBDTi1kb21haW4gdG8gcmVjb2du aXNlDQogICBQQ04tcGFja2V0cy4NCg0KNS4zLiAgUENOLWVncmVzcy1ub2RlIGZ1bmN0aW9ucw0K DQogICBFYWNoIGVncmVzcyBsaW5rIG9mIHRoZSBQQ04tZG9tYWluIGlzIHVwZ3JhZGVkIHdpdGgg dGhlIGZvbGxvd2luZw0KICAgZnVuY3Rpb25hbGl0eToNCg0KICAgbyAgUGFja2V0IGNsYXNzaWZ5 IC0gZGV0ZXJtaW5lIHdoaWNoIFBDTi1pbmdyZXNzLW5vZGUgYSBQQ04tcGFja2V0DQogICAgICBo YXMgY29tZSBmcm9tLg0KDQogICBvICBQQ04tbWV0ZXIgLSBtYWtlICJtZWFzdXJlbWVudHMgb2Yg UENOLXRyYWZmaWMiLiAgVGhlDQogICAgICBtZWFzdXJlbWVudChzKSBpcyBtYWRlIGFzIGFuIGFn Z3JlZ2F0ZSAoaWUgbm90IHBlciBmbG93KSBvZiBhbGwNCiAgICAgIFBDTi1wYWNrZXRzIGZyb20g YSBwYXJ0aWN1bGFyIFBDTi1pbmdyZXNzLW5vZGUuDQoNCiAgIG8gIFBDTi1jb2xvdXIgLSBmb3Ig UENOLXBhY2tldHMsIHNldCB0aGUgRFNDUCBmaWVsZCBvciBEU0NQIGFuZCBFQ04NCiAgICAgIGZp ZWxkcyB0byB0aGUgYXBwcm9wcmlhdGUgdmFsdWUocykgZm9yIHVzZSBvdXRzaWRlIHRoZSBQQ04t ZG9tYWluLg0KDQogICBBbm90aGVyIFBDTiBXRyBkb2N1bWVudCwgYWJvdXQgYm91bmRhcnkgbWVj aGFuaXNtcywgd2lsbCBkZXNjcmliZQ0KICAgd2hhdCB0aGUgIm1lYXN1cmVtZW50cyBvZiBQQ04t dHJhZmZpYyIgYXJlLiAgVGhpcyBkZXBlbmRzIG9uIHdoZXRoZXINCiAgIHRoZSBtZWFzdXJlbWVu dCBpcyB0YXJnZXRlZCBhdCBhZG1pc3Npb24gY29udHJvbCBvciBmbG93IHRlcm1pbmF0aW9uLg0K ICAgSXQgYWxzbyBkZXBlbmRzIG9uIHdoYXQgZW5jb2RpbmcgYW5kIFBDTi1tYXJraW5nIGFsZ29y aXRobXMgYXJlDQogICBzcGVjaWZpZWQgYnkgdGhlIFBDTiBXRy4NCg0KNS40LiAgQWRtaXNzaW9u IGNvbnRyb2wgZnVuY3Rpb25zDQoNCiAgIFNwZWNpZmljIGFkbWlzc2lvbiBjb250cm9sIGZ1bmN0 aW9ucyBjYW4gYmUgcGVyZm9ybWVkIGF0IGEgUENOLQ0KICAgYm91bmRhcnktbm9kZSAoUENOLWlu Z3Jlc3Mtbm9kZSBvciBQQ04tZWdyZXNzLW5vZGUpIG9yIGF0IGENCiAgIGNlbnRyYWxpc2VkIG5v ZGUsIGJ1dCBub3QgYXQgbm9ybWFsIFBDTi1pbnRlcmlvci1ub2Rlcy4gIFRoZQ0KICAgZnVuY3Rp b25zIGFyZToNCg0KICAgbyAgTWFrZSBkZWNpc2lvbiBhYm91dCBhZG1pc3Npb24gLSBjb21wYXJl IHRoZSByZXF1aXJlZCAibWVhc3VyZW1lbnRzDQogICAgICBvZiBQQ04tdHJhZmZpYyIgKG91dHB1 dCBvZiB0aGUgUENOLWVncmVzcy1ub2RlJ3MgUENOLW1ldGVyDQogICAgICBmdW5jdGlvbikgd2l0 aCBzb21lIHJlZmVyZW5jZSBsZXZlbCwgYW5kIGhlbmNlIGRlY2lkZSB3aGV0aGVyIHRvDQogICAg ICBhZG1pdCB0aGUgcG90ZW50aWFsIG5ldyBQQ04tZmxvdy4gIEFzIHdlbGwgYXMgdGhlIFBDTg0K ICAgICAgbWVhc3VyZW1lbnRzLCB0aGUgZGVjaXNpb24gdGFrZXMgYWNjb3VudCBvZiBwb2xpY3kg YW5kIGFwcGxpY2F0aW9uDQogICAgICBsYXllciByZXF1aXJlbWVudHMuDQoNCiAgIG8gIENvbW11 bmljYXRlIGRlY2lzaW9uIGFib3V0IGFkbWlzc2lvbiAtIHNpZ25hbCB0aGUgZGVjaXNpb24gdG8g dGhlDQogICAgICBub2RlIG1ha2luZyB0aGUgYWRtaXNzaW9uIGNvbnRyb2wgcmVxdWVzdCAod2hp Y2ggbWF5IGJlIG91dHNpZGUNCiAgICAgIHRoZSBQQ04tcmVnaW9uKSwgYW5kIHRvIHRoZSBwb2xp Y2VyIChQQ04taW5ncmVzcy1ub2RlIGZ1bmN0aW9uKQ0KDQogICBUaGVyZSBhcmUgdmFyaW91cyBw b3NzaWJpbGl0aWVzIGZvciBob3cgdGhlIGZ1bmN0aW9uYWxpdHkgY2FuIGJlDQogICBkaXN0cmli dXRlZCAod2UgYXNzdW1lIHRoZSBvcGVyYXRvciB3b3VsZCBjb25maWd1cmUgd2hpY2ggaXMgdXNl ZCk6DQoNCiAgIG8gIFRoZSBkZWNpc2lvbiBpcyBtYWRlIGF0IHRoZSBQQ04tZWdyZXNzLW5vZGUg YW5kIHNpZ25hbGxlZCB0byB0aGUNCiAgICAgIFBDTi1pbmdyZXNzLW5vZGUNCg0KDQoNCg0KRWFy ZGxleSAoRWRpdG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAgICAg ICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3VtZW50 ICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBvICBUaGUgZGVjaXNpb24g aXMgbWFkZSBhdCB0aGUgUENOLWluZ3Jlc3Mtbm9kZSwgd2hpY2ggcmVxdWlyZXMgdGhhdA0KICAg ICAgdGhlIFBDTi1lZ3Jlc3Mtbm9kZSBzaWduYWxzIHRvIHRoZSBQQ04taW5ncmVzcy1ub2RlIHRo ZSBmcmFjdGlvbg0KICAgICAgb2YgUENOLXRyYWZmaWMgdGhhdCBpcyBQQ04tbWFya2VkIChvciB3 aGF0ZXZlciB0aGUgUENOIFdHIGFncmVlcw0KICAgICAgYXMgdGhlIHJlcXVpcmVkICJtZWFzdXJl bWVudHMgb2YgUENOLXRyYWZmaWMiKS4NCg0KICAgbyAgVGhlIGRlY2lzaW9uIGlzIG1hZGUgYXQg YSBjZW50cmFsaXNlZCBub2RlLCB3aGljaCByZXF1aXJlcyB0aGF0DQogICAgICB0aGUgUENOLWVn cmVzcy1ub2RlIHNpZ25hbHMgaXRzIG1lYXN1cmVtZW50cyB0byB0aGUgY2VudHJhbGlzZWQNCiAg ICAgIG5vZGUsIGFuZCB0aGF0IHRoZSBjZW50cmFsaXNlZCBub2RlIHNpZ25hbHMgdG8gdGhlIFBD Ti1pbmdyZXNzLQ0KICAgICAgbm9kZSBhYm91dCB0aGUgZGVjaXNpb24gYWJvdXQgYWRtaXNzaW9u IGNvbnRyb2wuICBJdCB3b3VsZCBiZQ0KICAgICAgcG9zc2libGUgZm9yIHRoZSBjZW50cmFsaXNl ZCBub2RlIHRvIGJlIG9uZSBvZiB0aGUgUENOLWJvdW5kYXJ5LQ0KICAgICAgbm9kZXMsIHdoZW4g Y2xlYXJseSB0aGUgc2lnbmFsbGluZyB3b3VsZCBzb21ldGltZXMgYmUgcmVwbGFjZWQgYnkNCiAg ICAgIGEgbWVzc2FnZSBpbnRlcm5hbCB0byB0aGUgbm9kZS4NCg0KNS41LiAgUHJvYmluZyBmdW5j dGlvbnMNCg0KICAgUHJvYmluZyBmdW5jdGlvbnMgYXJlIG9wdGlvbmFsLCBhbmQgY2FuIGJlIHVz ZWQgZm9yIGFkbWlzc2lvbg0KICAgY29udHJvbC4gIEEgUENOLWluZ3Jlc3Mtbm9kZSBnZW5lcmF0 ZXMgYW5kIHNlbmRzIHByb2JlIHBhY2tldHMgaW4NCiAgIG9yZGVyIHRvIHRlc3QgdGhlIHByZS1j b25nZXN0aW9uIGxldmVsLiAgUHJvYmluZyBpcyB1c2VmdWwgb3IgZXZlbg0KICAgZXNzZW50aWFs IHVuZGVyIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoNCg0KICAgbyAgd2hlbiBhbiBpbmdyZXNz LWVncmVzcy1hZ2dyZWdhdGUgY2FycmllcyBubyB0cmFmZmljIChvciB0b28gbGl0dGxlDQogICAg ICB0cmFmZmljIGZvciB0aGUgUENOLWVncmVzcy1ub2RlIHRvIGFjY3VyYXRlbHkgbWFrZSB0aGUN CiAgICAgICJtZWFzdXJlbWVudHMgb2YgUENOLXRyYWZmaWMiIHRoYXQgYXJlIHJlcXVpcmVkIGZv ciBhbiBhZG1pc3Npb24NCiAgICAgIGRlY2lzaW9uKS4gIEl0IG1heSBiZSB0aGF0IHRoZSB0cmFm ZmljIGxldmVscyBvbiBvdGhlciBpbmdyZXNzLQ0KICAgICAgZWdyZXNzLWFnZ3JlZ2F0ZXMgYXJl IHNvIGhpZ2ggdGhhdCBhIG5ldyBmbG93IHNob3VsZG4ndCBiZQ0KICAgICAgYWRtaXR0ZWQgb24g dGhlICdlbXB0eScgaW5ncmVzcy1lZ3Jlc3MtYWdncmVnYXRlLiAgUHJvYmluZyBpcw0KICAgICAg dXNlZnVsIHRvIGNoZWNrIHRoaXMuDQoNCiAgIG8gIGluIHRoZSBwcmVzZW5jZSBvZiBtdWx0aXBh dGggcm91dGluZyAoRUNNUCkgYmV0d2VlbiB0aGUgUENOLQ0KICAgICAgYm91bmRhcnktbm9kZXMs IHdoZW4gc29tZSBwYXRocyBhcmUgcHJlLWNvbmdlc3RlZCB0aGVyZSBtYXkgYmUNCiAgICAgIG90 aGVyIHBhdGhzIHdoaWNoIGFyZW4ndCBwcmUtY29uZ2VzdGVkLiAgUHJvYmluZyBpcyB1c2VmdWwg dG8NCiAgICAgIGRldGVybWluZSB3aGV0aGVyIHRoZSBuZXcgZmxvdyB3b3VsZCBmb2xsb3cgYSBw YXRoIHRoYXQgaXNuJ3QgcHJlLQ0KICAgICAgY29uZ2VzdGVkIGFuZCBoZW5jZSBjYW4gYmUgYWRt aXR0ZWQuDQoNCiAgIFByb2JlIHBhY2tldHMgbWF5IGJlIHNpbXBsZSBkYXRhIGFkZHJlc3NlZCB0 byB0aGUgUENOLWVncmVzcy1ub2RlIGFuZA0KICAgcmVxdWlyZSBubyBwcm90b2NvbCBzdGFuZGFy ZGlzYXRpb24sIGFsdGhvdWdoIHRoZXJlIHdpbGwgYmUgYmVzdA0KICAgcHJhY3RpY2UgZm9yIHRo ZWlyIG51bWJlciwgc2l6ZSBhbmQgcmF0ZS4gIFRoZXJlIGFyZSB0d28NCiAgIHBvc3NpYmlsaXRp ZXMgZm9yIGhvdyBwcm9iaW5nIGlzIHRyaWdnZXJlZDoNCg0KICAgbyAgdGhlIFBDTi1lZ3Jlc3Mt bm9kZSByZXF1ZXN0cyAoc2lnbmFscykgdGhlIFBDTi1pbmdyZXNzLW5vZGUgdG8NCiAgICAgIGdl bmVyYXRlIHByb2JlIHRyYWZmaWMNCg0KICAgbyAgaWYgdGhlIFBDTi1pbmdyZXNzLW5vZGUga25v d3Mgd2hpY2ggUENOLWVncmVzcy1ub2RlIGlzIGFzc29jaWF0ZWQNCiAgICAgIHdpdGggdGhlIGRl c3RpbmF0aW9uIGFkZHJlc3MgaW4gdGhlIGFkbWlzc2lvbiByZXF1ZXN0LCB0aGVuIHRoZQ0KICAg ICAgUENOLWluZ3Jlc3Mtbm9kZSBjb3VsZCBrbm93IGl0IGhhcyBubyByZXNlcnZhdGlvbiB3aXRo IHRoYXQgUENOLQ0KICAgICAgZWdyZXNzLW5vZGUgYW5kIHVuaWxhdGVyYWxseSBzdGFydCBwcm9i aW5nLg0KDQogICBUaGUgcHJvYmluZyBmdW5jdGlvbnMgYXJlOg0KDQoNCg0KRWFyZGxleSAoRWRp dG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2Ug MTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3VtZW50ICAgICAgICAg ICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBvICBNYWtlIGRlY2lzaW9uIHRoYXQgcHJv YmluZyBpcyBuZWVkZWQNCg0KICAgbyAgKGlmIHJlcXVpcmVkKSBDb21tdW5pY2F0ZSB0aGUgcmVx dWVzdCB0aGF0IHByb2JpbmcgaXMgbmVlZGVkIC0gdGhlDQogICAgICBQQ04tZWdyZXNzLW5vZGUg c2lnbmFscyB0byB0aGUgUENOLWluZ3Jlc3Mtbm9kZSB0aGF0IHByb2JlIHRyYWZmaWMNCiAgICAg IGlzIG5lZWRlZA0KDQogICBvICBHZW5lcmF0ZSBwcm9iZSB0cmFmZmljIC0gdGhlIFBDTi1pbmdy ZXNzLW5vZGUgZ2VuZXJhdGVzIHRoZSBwcm9iZQ0KICAgICAgdHJhZmZpYy4gIFRoZSBhcHByb3By aWF0ZSBudW1iZXIgKG9yIHJhdGUpIG9mIHByb2JlIHBhY2tldHMgd2lsbA0KICAgICAgZGVwZW5k IG9uIHRoZSBQQ04tbWFya2luZyBhbGdvcml0aG07IGZvciBleGFtcGxlIGFuIGV4Y2Vzcy1yYXRl LQ0KICAgICAgbWFya2luZyBhbGdvcml0aG0gZ2VuZXJhdGVzIGZld2VyIFBDTi1tYXJrcyB0aGFu IGEgdGhyZXNob2xkLQ0KICAgICAgbWFya2luZyBhbGdvcml0aG0uDQoNCiAgIG8gIEZvcndhcmQg cHJvYmUgcGFja2V0cyAtIGFzIGZhciBhcyBQQ04taW50ZXJpb3Itbm9kZXMgYXJlDQogICAgICBj b25jZXJuZWQsIHByb2JlIHBhY2tldHMgbXVzdCBiZSBoYW5kbGVkIHRoZSBzYW1lIGFzIChvcmRp bmFyeQ0KICAgICAgZGF0YSkgUENOLXBhY2tldHMuDQoNCiAgIG8gIENvbnN1bWUgcHJvYmUgcGFj a2V0cyAtIHRoZSBQQ04tZWdyZXNzLW5vZGUgY29uc3VtZXMgcHJvYmUgcGFja2V0cw0KICAgICAg dG8gZW5zdXJlIHRoYXQgdGhleSBkb24ndCB0cmF2ZWwgYmV5b25kIHRoZSBQQ04tZG9tYWluLg0K DQo1LjYuICBGbG93IHRlcm1pbmF0aW9uIGZ1bmN0aW9ucw0KDQogICBTcGVjaWZpYyB0ZXJtaW5h dGlvbiBjb250cm9sIGZ1bmN0aW9ucyBjYW4gYmUgcGVyZm9ybWVkIGF0IGEgUENOLQ0KICAgYm91 bmRhcnktbm9kZSAoUENOLWluZ3Jlc3Mtbm9kZSBvciBQQ04tZWdyZXNzLW5vZGUpIG9yIGF0IGEN CiAgIGNlbnRyYWxpc2VkIG5vZGUsIGJ1dCBub3QgYXQgbm9ybWFsIFBDTi1pbnRlcmlvci1ub2Rl cy4gIFRoZXJlIGFyZQ0KICAgdmFyaW91cyBwb3NzaWJpbGl0aWVzIGZvciBob3cgdGhlIGZ1bmN0 aW9uYWxpdHkgY2FuIGJlIGRpc3RyaWJ1dGVkLA0KICAgc2ltaWxhciB0byB0aG9zZSBkaXNjdXNz ZWQgYWJvdmUgaW4gdGhlIEFkbWlzc2lvbiBjb250cm9sIHNlY3Rpb247DQogICB0aGUgZmxvdyB0 ZXJtaW5hdGlvbiBkZWNpc2lvbiBjb3VsZCBiZSBtYWRlIGF0IHRoZSBQQ04taW5ncmVzcy1ub2Rl LA0KICAgdGhlIFBDTi1lZ3Jlc3Mtbm9kZSBvciBhdCBzb21lIGNlbnRyYWxpc2VkIG5vZGUuICBU aGUgZnVuY3Rpb25zIGFyZToNCg0KICAgbyAgUENOLW1ldGVyIGF0IFBDTi1lZ3Jlc3Mtbm9kZSAt IChhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjMpIG1ha2UNCiAgICAgICJtZWFzdXJlbWVudHMg b2YgUENOLXRyYWZmaWMiIGZyb20gYSBwYXJ0aWN1bGFyIFBDTi1pbmdyZXNzLW5vZGUuDQoNCiAg IG8gIChpZiByZXF1aXJlZCkgUENOLW1ldGVyIGF0IFBDTi1pbmdyZXNzLW5vZGUgLSBtYWtlICJt ZWFzdXJlbWVudHMNCiAgICAgIG9mIFBDTi10cmFmZmljIiBiZWluZyBzZW50IHRvd2FyZHMgYSBw YXJ0aWN1bGFyIFBDTi1lZ3Jlc3Mtbm9kZTsNCiAgICAgIGFnYWluLCB0aGlzIGlzIGRvbmUgZm9y IHRoZSBpbmdyZXNzLWVncmVzcy1hZ2dyZWdhdGUgYW5kIG5vdCBwZXINCiAgICAgIGZsb3cuDQoN CiAgIG8gIChpZiByZXF1aXJlZCkgQ29tbXVuaWNhdGUgIm1lYXN1cmVtZW50cyBvZiBQQ04tdHJh ZmZpYyIgdG8gdGhlDQogICAgICBub2RlIHRoYXQgbWFrZXMgdGhlIGZsb3cgdGVybWluYXRpb24g ZGVjaXNpb24uICBGb3IgZXhhbXBsZSwgaWYNCiAgICAgIHRoZSBQQ04taW5ncmVzcy1ub2RlIG1h a2VzIHRoZSBkZWNpc2lvbiB0aGVuIGNvbW11bmljYXRlIHRoZSBQQ04tDQogICAgICBlZ3Jlc3Mt bm9kZSdzIG1lYXN1cmVtZW50cyB0byBpdCAoYXMgaW4NCiAgICAgIFtJLUQuYnJpc2NvZS10c3Z3 Zy1jbC1hcmNoaXRlY3R1cmVdKS4NCg0KICAgbyAgTWFrZSBkZWNpc2lvbiBhYm91dCBmbG93IHRl cm1pbmF0aW9uIC0gdXNlIHRoZSAibWVhc3VyZW1lbnRzIG9mDQogICAgICBQQ04tdHJhZmZpYyIg dG8gZGVjaWRlIHdoaWNoIFBDTi1mbG93IG9yIFBDTi1mbG93cyB0byB0ZXJtaW5hdGUuDQogICAg ICBUaGUgZGVjaXNpb24gdGFrZXMgYWNjb3VudCBvZiBwb2xpY3kgYW5kIGFwcGxpY2F0aW9uIGxh eWVyDQogICAgICByZXF1aXJlbWVudHMuDQoNCg0KDQoNCkVhcmRsZXkgKEVkaXRvcikgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDA3DQoNCg0KICAgbyAgQ29tbXVuaWNhdGUgZGVjaXNpb24gYWJvdXQgZmxvdyB0 ZXJtaW5hdGlvbiAtIHNpZ25hbCB0aGUgZGVjaXNpb24NCiAgICAgIHRvIHRoZSBub2RlIHRoYXQg aXMgYWJsZSB0byB0ZXJtaW5hdGUgdGhlIGZsb3cgKHdoaWNoIG1heSBiZQ0KICAgICAgb3V0c2lk ZSB0aGUgUENOLXJlZ2lvbiksIGFuZCB0byB0aGUgcG9saWNlciAoUENOLWluZ3Jlc3Mtbm9kZQ0K ICAgICAgZnVuY3Rpb24pDQoNCiAgIE9uZSBwYXJ0aWN1bGFyIHByb3Bvc2FsLCBbSS1ELmNoYXJu eS1wY24tc2luZ2xlLW1hcmtpbmddLCBmb3IgUENOLQ0KICAgbWFya2luZyBhbmQgcGVyZm9ybWlu ZyBmbG93IGFkbWlzc2lvbiBhbmQgdGVybWluYXRpb24gd291bGQgcmVxdWlyZSBhDQogICBnbG9i YWwgcGFyYW1ldGVyIHRvIGJlIGRlZmluZWQgb24gYWxsIFBDTi1ib3VuZGFyeS1ub2RlcyBpbiB0 aGUgUENOLQ0KICAgZG9tYWluLiAgW0ktRC5jaGFybnktcGNuLXNpbmdsZS1tYXJraW5nXSBkaXNj dXNzZXMgaW4gZnVsbCB0aGUgaW1wYWN0DQogICBvZiB0aGlzIHBhcnRpY3VsYXIgcHJvcG9zYWwg b24gdGhlIG9wZXJhdGlvbiBvZiBQQ04uDQoNCjUuNy4gIEFkZHJlc3NpbmcNCg0KICAgUENOLW5v ZGVzIG1heSBuZWVkIHRvIGtub3cgdGhlIGFkZHJlc3Mgb2Ygb3RoZXIgUENOLW5vZGVzOg0KDQog ICBvICBpbiBhbGwgY2FzZXMgUENOLWludGVyaW9yLW5vZGVzIGRvbid0IG5lZWQgdG8ga25vdyB0 aGUgYWRkcmVzcyBvZg0KICAgICAgYW55IG90aGVyIFBDTi1ub2RlcywgZXhjZXB0IHRoZWlyIG5l eHQgaG9wIG5laWdoYm91cnMNCg0KICAgbyAgaW4gdGhlIGNhc2VzIG9mIGFkbWlzc2lvbiBvciB0 ZXJtaW5hdGlvbiBkZWNpc2lvbiBieSBhIFBDTi0NCiAgICAgIGJvdW5kYXJ5LW5vZGUsIHRoZSBQ Q04tZWdyZXNzLW5vZGUgbmVlZHMgdG8ga25vdyB0aGUgYWRkcmVzcyBvZg0KICAgICAgdGhlIFBD Ti1pbmdyZXNzLW5vZGUgYXNzb2NpYXRlZCB3aXRoIGEgZmxvdywgYXQgYSBtaW5pbXVtIHNvIHRo YXQNCiAgICAgIHRoZSBQQ04taW5ncmVzcy1ub2RlIGNhbiBiZSBpbmZvcm1lZCB0byBlbmZvcmNl IHRoZSBhZG1pc3Npb24NCiAgICAgIGRlY2lzaW9uIHRocm91Z2ggcG9saWNpbmcuICBUaGUgYWRk cmVzc2luZyBpbmZvcm1hdGlvbiBjYW4gYmUNCiAgICAgIGdhdGhlcmVkIGZyb20gc2lnbmFsbGlu ZywgZm9yIGV4YW1wbGUgYXMgZGVzY3JpYmVkIGZvciBSU1ZQIGluDQogICAgICBbSS1ELmxlZmF1 Y2hldXItcnN2cC1lY25dLiAgQWx0ZXJuYXRpdmVseSwgaWYgUENOLXRyYWZmaWMgaXMNCiAgICAg IGFsd2F5cyB0dW5uZWxsZWQgYWNyb3NzIHRoZSBQQ04tZG9tYWluLCB0aGVuIHRoZSBQQ04taW5n cmVzcy0NCiAgICAgIG5vZGUncyBhZGRyZXNzIGlzIHNpbXBseSB0aGUgc291cmNlIGFkZHJlc3Mg b2YgdGhlIG91dGVyIHBhY2tldA0KICAgICAgaGVhZGVyLg0KDQogICBvICBpbiB0aGUgY2FzZXMg b2YgYWRtaXNzaW9uIG9yIHRlcm1pbmF0aW9uIGRlY2lzaW9uIGJ5IGEgY2VudHJhbA0KICAgICAg Y29udHJvbCBub2RlLCB0aGUgUENOLWVncmVzcy1ub2RlIG5lZWRzIHRvIGJlIGNvbmZpZ3VyZWQg d2l0aCB0aGUNCiAgICAgIGFkZHJlc3Mgb2YgdGhlIGNlbnRyYWxpc2VkIG5vZGUuICBJbiBhZGRp dGlvbiwgZGVwZW5kaW5nIG9uIHRoZQ0KICAgICAgZXhhY3QgZGVwbG95bWVudCBzY2VuYXJpbyBh bmQgaXRzIHNpZ25hbGxpbmcsIHRoZSBjZW50cmFsaXNlZCBub2RlDQogICAgICBtYXkgbmVlZCB0 byBrbm93IHRoZSBhZGRyZXNzZXMgb2YgdGhlIFBDTi1pbmdyZXNzLW5vZGUgYW5kIFBDTi0NCiAg ICAgIGVncmVzcy1ub2RlLCBhbmQgdGhlIFBDTi1lZ3Jlc3Mtbm9kZSBrbm93IHRoZSBhZGRyZXNz IG9mIHRoZSBQQ04tDQogICAgICBpbmdyZXNzLW5vZGUuICBOT1RFOiBDb25zaWRlcmF0aW9uIG9m IHRoZSBjZW50cmFsaXNlZCBjYXNlIGlzIG91dA0KICAgICAgb2Ygc2NvcGUgb2YgdGhlIGluaXRp YWwgUENOIFdHIENoYXJ0ZXIuDQoNCjUuOC4gIFR1bm5lbGxpbmcNCg0KICAgSXQgaXMgcG9zc2li bGUgdGhhdCB0dW5uZWxzIHRlcm1pbmF0ZSBhdCBhIFBDTi1ub2RlLiAgSXQgaXMgaW1wb3J0YW50 DQogICB0aGF0IGFueSBQQ04tbWFya2luZyBpcyBwcmVzZXJ2ZWQgYWZ0ZXIgZGVjYXBzdWxhdGlv biwgc28gdGhhdCBpdCBpcw0KICAgc3RpbGwgc2VlbiBieSB0aGUgUENOLWVncmVzcy1ub2RlLiAg VG8gZW5zdXJlIHRoaXMsIG9uIGRlY2Fwc3VsYXRpb24NCiAgIHRoZSBmb2xsb3dpbmcgcnVsZXMg YXJlIGFwcGxpZWQ6DQoNCiAgIG8gIHRoZSBQQ04tbWFya2luZyBzdGF0ZSBvZiB0aGUgaW5uZXIg YW5kIG91dGVyIGhlYWRlcnMgYXJlIGNvbXBhcmVkDQoNCg0KDQoNCg0KRWFyZGxleSAoRWRpdG9y KSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2UgMTld DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3VtZW50ICAgICAgICAgICAg ICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBvICBpZiB0aGUgaW5uZXIgaGVhZGVyJ3MgbWFy a2luZyBzdGF0ZSBpcyBtb3JlIHNldmVyZSB0aGVuIGl0IGlzDQogICAgICBwcmVzZXJ2ZWQNCg0K ICAgbyAgaWYgdGhlIG91dGVyIGhlYWRlcidzIG1hcmtpbmcgc3RhdGUgaXMgbW9yZSBzZXZlcmUg dGhlbiBpdCBpcw0KICAgICAgY29waWVkIG9udG8gdGhlIGlubmVyIGhlYWRlcg0KDQogICBvICBO QiB0aGUgb3JkZXIgb2YgaW5jcmVhc2luZyBzZXZlcml0eSBpczogdW5tYXJrZWQ7IFBDTi1tYXJr aW5nIHdpdGgNCiAgICAgIGZpcnN0IGVuY29kaW5nIChpZSBhc3NvY2lhdGVkIHdpdGggdGhlIFBD Ti1sb3dlci1yYXRlKTsgUENOLQ0KICAgICAgbWFya2luZyB3aXRoIHNlY29uZCBlbmNvZGluZyAo aWUgYXNzb2NpYXRlZCB3aXRoIHRoZSBQQ04tdXBwZXItDQogICAgICByYXRlKQ0KDQogICBTaW1p bGFybHksIGlmIGVuY2Fwc3VsYXRpb24gaXMgZG9uZSB3aXRoaW4gdGhlIFBDTi1kb21haW4sIHRo ZW4gdGhlDQogICBmb2xsb3dpbmcgcnVsZSBpcyBhcHBsaWVkOg0KDQogICBvICBhbnkgUENOLW1h cmtpbmcgaXMgY29waWVkIGludG8gdGhlIG91dGVyIGhlYWRlcg0KDQogICBUdW5uZWxsaW5nIGNv bnNpZGVyYXRpb25zIGFsc28gZGVwZW5kIG9uIHdoaWNoIGhlYWRlciBiaXRzIHRoZSBQQ04gV0cN CiAgIGRlY2lkZXMgdG8gdXNlLiAgSWYgdGhlIEVDTiBiaXRzIGFyZSB1c2VkIHRoZW4NCiAgIFtJ LUQuYnJpc2NvZS10c3Z3Zy1lY24tdHVubmVsXSBhcHBsaWVzOyB0aGUgcnVsZXMgYWJvdmUgY29u Zm9ybSB0bw0KICAgaXRzIHNwaXJpdC4gIElmIHRoZSBEU0NQIGZpZWxkIGlzIHVzZWQgdGhlbiBb UkZDMjk4M10gbmVlZHMgdG8gYmUNCiAgIGNvbnNpZGVyZWQgY2FyZWZ1bGx5Lg0KDQogICBBbiBv cGVyYXRvciBtYXkgd2lzaCB0byB0dW5uZWwgUENOLXRyYWZmaWMgZnJvbSBQQ04taW5ncmVzcy1u b2RlcyB0bw0KICAgUENOLWVncmVzcy1ub2RlcywgaW4gd2hpY2ggY2FzZSB0aGUgcnVsZXMgYWJv dmUgYXJlbid0IG5lZWRlZC4gIFRoZQ0KICAgcG90ZW50aWFsIHJlYXNvbnMgZm9yIGRvaW5nIHN1 Y2ggdHVubmVsbGluZyBhcmU6IHRoZSBQQ04tZWdyZXNzLW5vZGUNCiAgIHRoZW4gYXV0b21hdGlj YWxseSBrbm93cyB0aGUgYWRkcmVzcyBvZiB0aGUgcmVsZXZhbnQgUENOLWluZ3Jlc3Mtbm9kZQ0K ICAgZm9yIGEgZmxvdzsgZXZlbiBpZiBFQ01QIGlzIHJ1bm5pbmcsIGFsbCBQQ04tcGFja2V0cyBv biBhIHBhcnRpY3VsYXINCiAgIGluZ3Jlc3MtZWdyZXNzLWFnZ3JlZ2F0ZSBmb2xsb3cgdGhlIHNh bWUgcGF0aC4gIEJ1dCBpdCBhbHNvIGhhcw0KICAgZHJhd2JhY2tzOiBhZGRpdGlvbmFsIG92ZXJo ZWFkIGluIHRlcm1zIG9mIGJhbmR3aWR0aCBhbmQgcHJvY2Vzc2luZzsNCiAgIGFuZCB0aGUgZWZm ZWN0aXZlIGVsaW1pbmF0aW9uIG9mIEVDTVAgYXMgYSBsb2FkIGJhbGFuY2luZyBtZWNoYW5pc20u DQoNCjUuOS4gIEZhdWx0IGhhbmRsaW5nDQoNCiAgIElmIGEgUENOLWludGVyaW9yLW5vZGUgZmFp bHMgKG9yIG9uZSBvZiBpdHMgbGlua3MpLCB0aGVuIGxvd2VyIGxheWVyDQogICBwcm90ZWN0aW9u IG1lY2hhbmlzbXMgb3IgdGhlIHJlZ3VsYXIgSVAgcm91dGluZyBwcm90b2NvbCB3aWxsDQogICBl dmVudHVhbGx5IHJlLXJvdXRlIHJvdW5kIGl0LiAgSWYgdGhlIG5ldyByb3V0ZSBjYW4gY2Fycnkg YWxsIHRoZQ0KICAgYWRtaXR0ZWQgdHJhZmZpYywgZmxvd3Mgd2lsbCBncmFjZWZ1bGx5IGNvbnRp bnVlLiAgSWYgaW5zdGVhZCB0aGlzDQogICBjYXVzZXMgZWFybHkgd2FybmluZyBvZiBwcmUtY29u Z2VzdGlvbiBvbiB0aGUgbmV3IHJvdXRlLCB0aGVuDQogICBhZG1pc3Npb24gY29udHJvbCBiYXNl ZCBvbiBwcmUtY29uZ2VzdGlvbiBub3RpZmljYXRpb24gd2lsbCBlbnN1cmUNCiAgIG5ldyBmbG93 cyB3aWxsIG5vdCBiZSBhZG1pdHRlZCB1bnRpbCBlbm91Z2ggZXhpc3RpbmcgZmxvd3MgaGF2ZQ0K ICAgZGVwYXJ0ZWQuICBGaW5hbGx5IHJlLXJvdXRpbmcgbWF5IHJlc3VsdCBpbiBoZWF2eSAocHJl LSljb25nZXN0aW9uLA0KICAgd2hlbiB0aGUgZmxvdyB0ZXJtaW5hdGlvbiBtZWNoYW5pc20gd2ls bCBraWNrIGluLg0KDQogICBJZiBhIFBDTi1ib3VuZGFyeS1ub2RlIGZhaWxzIHRoZW4gd2Ugd291 bGQgbGlrZSB0aGUgcmVndWxhciBRb1MNCiAgIHNpZ25hbGxpbmcgcHJvdG9jb2wgdG8gdGFrZSBj YXJlIG9mIHRoaW5ncy4gIEFzIGFuIGV4YW1wbGUNCiAgIFtJLUQuYnJpc2NvZS10c3Z3Zy1jbC1h cmNoaXRlY3R1cmVdIGNvbnNpZGVycyB3aGF0IGhhcHBlbnMgaWYgUlNWUCBpcw0KICAgdGhlIFFv UyBzaWduYWxsaW5nIHByb3RvY29sLiAgVGhlIGRldGFpbHMgZm9yIGEgc3BlY2lmaWMgc2lnbmFs bGluZw0KICAgcHJvdG9jb2wgYXJlIG91dCBvZiBzY29wZSBvZiB0aGUgUENOIFdHLCBob3dldmVy IHRoZXJlIGlzIGEgV0cNCg0KDQoNCkVhcmRsZXkgKEVkaXRvcikgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3 DQoNCg0KICAgTWlsZXN0b25lIG9uIGdlbmVyaWMgIlJlcXVpcmVtZW50cyBmb3Igc2lnbmFsbGlu ZyIuDQoNCg0KNi4gIERlc2lnbiBnb2FscyBhbmQgY2hhbGxlbmdlcw0KDQogICBQcmlvciB3b3Jr IG9uIFBDTiBhbmQgc2ltaWxhciBtZWNoYW5pc21zIGhhcyB0aHJvd24gdXAgYSBudW1iZXIgb2YN CiAgIGNvbnNpZGVyYXRpb25zIGFib3V0IFBDTidzIGRlc2lnbiBnb2FscyAodGhpbmdzIFBDTiBz aG91bGQgYmUgZ29vZA0KICAgYXQpIGFuZCBzb21lIGlzc3VlcyB0aGF0IGhhdmUgYmVlbiBoYXJk IHRvIHNvbHZlIGluIGEgZnVsbHkNCiAgIHNhdGlzZmFjdG9yeSBtYW5uZXIuICBUYWtlbiBhcyBh IHdob2xlIGl0IHJlcHJlc2VudHMgYSBsaXN0IG9mIHRyYWRlLQ0KICAgb2ZmcyAoaXQncyB1bmxp a2VseSB0aGF0IHRoZXkgY2FuIGFsbCBiZSAxMDAlIGFjaGlldmVkKSBhbmQgcGVyaGFwcw0KICAg YXMgZXZhbHVhdGlvbiBjcml0ZXJpYSB0byBoZWxwIGFuIG9wZXJhdG9yIChvciB0aGUgSUVURikg ZGVjaWRlDQogICBiZXR3ZWVuIG9wdGlvbnMuDQoNCiAgIFRoZSBmb2xsb3dpbmcgYXJlIGtleSBk ZXNpZ24gZ29hbHMgZm9yIFBDTiAoYmFzZWQgb24NCiAgIFtJLUQuY2hhbi1wY24tcHJvYmxlbS1z dGF0ZW1lbnRdKToNCg0KICAgbyAgVGhlIFBDTi1lbmFibGVkIHBhY2tldCBmb3J3YXJkaW5nIG5l dHdvcmsgc2hvdWxkIGJlIHNpbXBsZSwNCiAgICAgIHNjYWxhYmxlIGFuZCByb2J1c3QNCg0KICAg byAgQ29tcGF0aWJpbGl0eSB3aXRoIG90aGVyIHRyYWZmaWMgKGkuZS4gYSBwcm9wb3NlZCBzb2x1 dGlvbiBzaG91bGQNCiAgICAgIHdvcmsgd2VsbCB3aGVuIG5vbi1QQ04gdHJhZmZpYyBpcyBhbHNv IHByZXNlbnQgaW4gdGhlIG5ldHdvcmspDQoNCiAgIG8gIFN1cHBvcnQgb2YgZGlmZmVyZW50IHR5 cGVzIG9mIHJlYWwtdGltZSB0cmFmZmljIChlZyBzaG91bGQgd29yaw0KICAgICAgd2VsbCB3aXRo IENCUiBhbmQgVkJSIHZvaWNlIGFuZCB2aWRlbyBzb3VyY2VzIHRyZWF0ZWQgdG9nZXRoZXIpDQoN CiAgIG8gIFJlYWN0aW9uIHRpbWUgb2YgdGhlIG1lY2hhbmlzbXMgc2hvdWxkIGJlIGNvbW1lbnN1 cmF0ZSB3aXRoIHRoZQ0KICAgICAgZGVzaXJlZCBhcHBsaWNhdGlvbi1sZXZlbCByZXF1aXJlbWVu dHMgKGUuZy4gYSB0ZXJtaW5hdGlvbg0KICAgICAgbWVjaGFuaXNtIG5lZWRzIHRvIHRlcm1pbmF0 ZSBmbG93cyBiZWZvcmUgc2lnbmlmaWNhbnQgUW9TIGlzc3Vlcw0KICAgICAgYXJlIGV4cGVyaWVu Y2VkIGJ5IHJlYWwtdGltZSB0cmFmZmljLCBhbmQgYmVmb3JlIG1vc3QgdXNlcnMgaGFuZw0KICAg ICAgdXApDQoNCiAgIG8gIENvbXBhdGliaWxpdHkgd2l0aCBkaWZmZXJlbnQgcHJlY2VkZW5jZSBs ZXZlbHMgb2YgcmVhbC10aW1lDQogICAgICBhcHBsaWNhdGlvbnMgKGUuZy4gcHJlZmVyZW50aWFs IHRyZWF0bWVudCBvZiBoaWdoZXIgcHJlY2VkZW5jZQ0KICAgICAgY2FsbHMgb3ZlciBsb3dlciBw cmVjZWRlbmNlIGNhbGxzLCBbSVRVLU1MUFBdLg0KDQogICBUaGUgZm9sbG93aW5nIGFyZSBvcGVu IGlzc3Vlcy4gIFRoZXkgYXJlIHRha2VuIGZyb20NCiAgIFtJLUQuYnJpc2NvZS10c3Z3Zy1jbC1h cmNoaXRlY3R1cmVdIHdoaWNoIGFsc28gZGVzY3JpYmVzIHNvbWUNCiAgIHBvc3NpYmxlIHNvbHV0 aW9ucyAocG90ZW50aWFsIHNvbHV0aW9ucyBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzDQogICBk b2N1bWVudCkuICBOb3RlIHRoYXQgc29tZSBtYXkgYmUgY29uc2lkZXJlZCB1bmltcG9ydGFudCBp biBnZW5lcmFsDQogICBvciBpbiBzcGVjaWZpYyBkZXBsb3ltZW50IHNjZW5hcmlvcy4NCg0KICAg byAgRUNNUCAoRXF1YWwgQ29zdCBNdWx0aS1QYXRoKSBSb3V0aW5nOiBUaGUgbGV2ZWwgb2YgcHJl LWNvbmdlc3Rpb24NCiAgICAgIGlzIG1lYXN1cmVkIG9uIGEgc3BlY2lmaWMgaW5ncmVzcy1lZ3Jl c3MtYWdncmVnYXRlLiAgSG93ZXZlciwgaWYNCiAgICAgIHRoZSBQQ04tZG9tYWluIHJ1bnMgRUNN UCwgdGhlbiB0cmFmZmljIG9uIHRoaXMgaW5ncmVzcy1lZ3Jlc3MtDQogICAgICBhZ2dyZWdhdGUg bWF5IGZvbGxvdyBzZXZlcmFsIGRpZmZlcmVudCBwYXRocyAtIHNvbWUgb2YgdGhlIHBhdGhzDQog ICAgICBjb3VsZCBiZSBwcmUtY29uZ2VzdGVkIHdoaWxzdCBvdGhlcnMgYXJlIG5vdC4gIFRoZXJl IGFyZSB0d28NCiAgICAgIHBvdGVudGlhbCBwcm9ibGVtczoNCg0KDQoNCg0KRWFyZGxleSAoRWRp dG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2Ug MjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3VtZW50ICAgICAgICAg ICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICAgICAxLiAgb3Zlci1hZG1pc3Npb246IGEg bmV3IGZsb3cgaXMgYWRtaXR0ZWQgKGJlY2F1c2UgdGhlIHByZS0NCiAgICAgICAgICBjb25nZXN0 aW9uIGxldmVsIG1lYXN1cmVkIGJ5IHRoZSBQQ04tZWdyZXNzLW5vZGUgaXMNCiAgICAgICAgICBz dWZmaWNpZW50bHkgZGlsdXRlZCBieSB1bm1hcmtlZCBwYWNrZXRzIGZyb20gbm9uLWNvbmdlc3Rl ZA0KICAgICAgICAgIHBhdGhzIHRoYXQgYSBuZXcgZmxvdyBpcyBhZG1pdHRlZCksIGJ1dCBpdHMg cGFja2V0cyB0cmF2ZWwNCiAgICAgICAgICB0aHJvdWdoIGEgcHJlLWNvbmdlc3RlZCBQQ04tbm9k ZQ0KDQogICAgICAyLiAgaW5lZmZlY3RpdmUgdGVybWluYXRpb246IGZsb3dzIGFyZSB0ZXJtaW5h dGVkLCBob3dldmVyIHRoZWlyDQogICAgICAgICAgcGF0aCBkb2Vzbid0IHRyYXZlbCB0aHJvdWdo IHRoZSAocHJlLSljb25nZXN0ZWQgcm91dGVyKHMpLg0KDQogICAgICBUaGUgb3ZlcmFsbCBQQ04g c29sdXRpb24gZm9yIGZsb3cgdGVybWluYXRpb24gbXVzdCBzb2x2ZSB0aGUNCiAgICAgIHNlY29u ZCBwcm9ibGVtLCBzaW5jZSBmbG93IHRlcm1pbmF0aW9uIGlzIGEgJ2xhc3QgcmVzb3J0Jy4gIEZv cg0KICAgICAgZmxvdyBhZG1pc3Npb24sIHRoZSByaXNrIG9mIHNsaWdodCBvdmVyLWFkbWlzc2lv biBtYXkgYmUNCiAgICAgIGFjY2VwdGFibGUgKHBhcnRpY3VsYXJseSB3aXRoIGZsb3cgdGVybWlu YXRpb24gYXMgYSBmYWxsLWJhY2spLCBhdA0KICAgICAgbGVhc3QgZm9yIHNvbWUgb3BlcmF0b3Jz Lg0KDQogICBvICBCaS1EaXJlY3Rpb25hbCBTZXNzaW9uczogTWFueSBhcHBsaWNhdGlvbnMgaGF2 ZSBiaS1kaXJlY3Rpb25hbA0KICAgICAgc2Vzc2lvbnMgLSBoZW5jZSB0aGVyZSBhcmUgdHdvIGZs b3dzIHRoYXQgc2hvdWxkIGJlIGFkbWl0dGVkIChvcg0KICAgICAgdGVybWluYXRlZCkgYXMgYSBw YWlyIC0gZm9yIGluc3RhbmNlIGEgYmktZGlyZWN0aW9uYWwgdm9pY2UgY2FsbA0KICAgICAgb25s eSBtYWtlcyBzZW5zZSBpZiBmbG93cyBpbiBib3RoIGRpcmVjdGlvbnMgYXJlIGFkbWl0dGVkLg0K ICAgICAgSG93ZXZlciwgUENOJ3MgbWVjaGFuaXNtcyBjb25jZXJuIGFkbWlzc2lvbiBhbmQgdGVy bWluYXRpb24gb2YgYQ0KICAgICAgc2luZ2xlIGZsb3csIGFuZCBjb29yZGluYXRpb24gb2YgdGhl IGRlY2lzaW9uIGZvciBib3RoIGZsb3dzIGlzIGENCiAgICAgIG1hdHRlciBmb3IgdGhlIHNpZ25h bGxpbmcgcHJvdG9jb2wgYW5kIG91dCBvZiBzY29wZSBvZiBQQ04uICBPbmUNCiAgICAgIHBvc3Np YmxlIGV4YW1wbGUgd291bGQgdXNlIFNJUCBwcmUtY29uZGl0aW9uczsgdGhlcmUgYXJlIG90aGVy cy4NCg0KICAgbyAgR2xvYmFsIENvb3JkaW5hdGlvbjogUENOIG1ha2VzIGl0cyBhZG1pc3Npb24g ZGVjaXNpb24gYmFzZWQgb24NCiAgICAgIFBDTi1tYXJraW5ncyBvbiBhIHBhcnRpY3VsYXIgaW5n cmVzcy1lZ3Jlc3MtYWdncmVnYXRlLiAgRGVjaXNpb25zDQogICAgICBhYm91dCBmbG93cyB0aHJv dWdoIGEgZGlmZmVyZW50IGluZ3Jlc3MtZWdyZXNzLWFnZ3JlZ2F0ZSBhcmUgbWFkZQ0KICAgICAg aW5kZXBlbmRlbnRseS4gIEhvd2V2ZXIsIG9uZSBjYW4gaW1hZ2luZSBuZXR3b3JrIHRvcG9sb2dp ZXMgYW5kDQogICAgICB0cmFmZmljIG1hdHJpY2VzIHdoZXJlIGZyb20gYSBnbG9iYWwgcGVyc3Bl Y3RpdmUgaXQgd291bGQgYmUNCiAgICAgIGJldHRlciB0byBtYWtlIGEgY29vcmRpbmF0ZWQgZGVj aXNpb24gYWNyb3NzIGFsbCB0aGUgaW5ncmVzcy0NCiAgICAgIGVncmVzcy1hZ2dyZWdhdGVzIGZv ciB0aGUgd2hvbGUgUENOLWRvbWFpbi4gIEZvciBleGFtcGxlLCB0byBibG9jaw0KICAgICAgKG9y IGV2ZW4gdGVybWluYXRlKSBmbG93cyBvbiBvbmUgaW5ncmVzcy1lZ3Jlc3MtYWdncmVnYXRlIHNv IHRoYXQNCiAgICAgIG1vcmUgaW1wb3J0YW50IGZsb3dzIHRocm91Z2ggYSBkaWZmZXJlbnQgaW5n cmVzcy1lZ3Jlc3MtYWdncmVnYXRlDQogICAgICBjb3VsZCBiZSBhZG1pdHRlZC4gIE1lY2hhbmlz bXMgdG8gc29sdmUgdGhlc2UgcHJvYmxlbXMgbWF5IHdlbGwgYmUNCiAgICAgIG91dCBvZiBzY29w ZS4NCg0KICAgbyAgQWdncmVnYXRlIFRyYWZmaWMgQ2hhcmFjdGVyaXN0aWNzOiBFdmVuIHdoZW4g dGhlIG51bWJlciBvZiBmbG93cw0KICAgICAgaXMgc3RhYmxlLCB0aGUgdHJhZmZpYyBsZXZlbCB0 aHJvdWdoIHRoZSBQQ04tZG9tYWluIHdpbGwgdmFyeQ0KICAgICAgYmVjYXVzZSB0aGUgc291cmNl cyB2YXJ5IHRoZWlyIHRyYWZmaWMgcmF0ZXMuICBQQ04gd29ya3MgYmVzdCB3aGVuDQogICAgICB0 aGVyZSdzIG5vdCB0b28gbXVjaCB2YXJpYWJpbGl0eSBpbiB0aGUgdG90YWwgdHJhZmZpYyBsZXZl bCBhdCBhDQogICAgICBQQ04tbm9kZSdzIGludGVyZmFjZSAoaWUgaW4gdGhlIGFnZ3JlZ2F0ZSB0 cmFmZmljIGZyb20gYWxsDQogICAgICBzb3VyY2VzKS4gIFRvbyBtdWNoIHZhcmlhdGlvbiBtZWFu cyB0aGF0IGEgbm9kZSBtYXkgKGF0IG9uZQ0KICAgICAgbW9tZW50KSBub3QgYmUgZG9pbmcgYW55 IFBDTi1tYXJraW5nIGFuZCB0aGVuIChhdCBhbm90aGVyIG1vbWVudCkNCiAgICAgIGRyb3AgcGFj a2V0cyBiZWNhdXNlIGl0J3Mgb3ZlcmxvYWRlZC4gIFRoaXMgbWFrZXMgaXQgaGFyZCB0byB0dW5l DQogICAgICB0aGUgYWRtaXNzaW9uIGNvbnRyb2wgc2NoZW1lIHRvIHN0b3AgYWRtaXR0aW5nIG5l dyBmbG93cyBhdCB0aGUNCiAgICAgIHJpZ2h0IHRpbWUuDQoNCg0KDQoNCg0KRWFyZGxleSAoRWRp dG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2Ug MjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3VtZW50ICAgICAgICAg ICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBvICBGbGFzaCBjcm93ZHMgYW5kIFNwZWVk IG9mIFJlYWN0aW9uOiBQQ04gaXMgYSBtZWFzdXJlbWVudC1iYXNlZA0KICAgICAgbWVjaGFuaXNt IGFuZCBzbyBoYXMgYSBsaW1pdGVkIHNwZWVkIG9mIHJlYWN0aW9uLiAgRm9yIGV4YW1wbGUsDQog ICAgICBwb3RlbnRpYWxseSBpZiBhIGJpZyBidXJzdCBvZiBhZG1pc3Npb24gcmVxdWVzdHMgb2Nj dXJzIGluIGEgdmVyeQ0KICAgICAgc2hvcnQgc3BhY2Ugb2YgdGltZSAoZWcgcHJvbXB0ZWQgYnkg YSB0ZWxldm90ZSksIHRoZXkgY291bGQgYWxsDQogICAgICBnZXQgYWRtaXR0ZWQgYmVmb3JlIGVu b3VnaCBQQ04tbWFya3MgYXJlIHNlZW4gdG8gYmxvY2sgbmV3IGZsb3dzLg0KICAgICAgSW4gb3Ro ZXIgd29yZHMsIGFueSBhZGRpdGlvbmFsIGxvYWQgb2ZmZXJlZCB3aXRoaW4gdGhlIHJlYWN0aW9u DQogICAgICB0aW1lIG9mIHRoZSBtZWNoYW5pc20gbXVzdG4ndCBtb3ZlIHRoZSBQQ04tZG9tYWlu IGRpcmVjdGx5IGZyb20gbm8NCiAgICAgIGNvbmdlc3Rpb24gdG8gb3ZlcmxvYWQuICBUaGlzICd2 dWxuZXJhYmlsaXR5IHBlcmlvZCcgbWF5IGltcGFjdCBhdA0KICAgICAgdGhlIHNpZ25hbGxpbmcg bGV2ZWwsIGZvciBpbnN0YW5jZSBRb1MgcmVxdWVzdHMgc2hvdWxkbid0IGJlDQogICAgICBoYW5k bGVkIGFueSBmYXN0ZXIgdGhhbiB0aGUgdnVsbmVyYWJpbGl0eSBwZXJpb2QuDQoNCiAgIG8gIENv bXBhdGliaWxpdHkgb2YgUENOLWVuY29kaW5nIHdpdGggRUNOLWVuY29kaW5nLiAgVGhpcyBpc3N1 ZSB3aWxsDQogICAgICBiZSBjb25zaWRlcmVkIGZ1cnRoZXIgaW4gW0ktRC5jaGFuLXBjbi1lbmNv ZGluZy1jb21wYXJpc29uXS4NCg0KDQo3LiAgT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudA0KDQog ICBFRElUT1InUyBOT1RFOiBBIHJlLXdyaXRlIG9mIHRoaXMgc2VjdGlvbiBpcyBwbGFubmVkOyBz b21lIG9mIHRoZQ0KICAgc3ViLXNlY3Rpb25zIGFyZSB2ZXJ5IHNob3J0ISAgVGhlIFBDTiBXRyBD aGFydGVyIHNheXMgdGhhdCB0aGUNCiAgIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzaG91bGQgaW5j bHVkZSBzZWN1cml0eSwgbWFuYWdlYWJpbGl0eSBhbmQNCiAgIG9wZXJhdGlvbmFsIGNvbnNpZGVy YXRpb25zLg0KDQogICBUaGlzIFNlY3Rpb24gY29uc2lkZXJzIG9wZXJhdGlvbnMgYW5kIG1hbmFn ZW1lbnQgaXNzdWVzLCB1bmRlciB0aGUNCiAgIEZDQVBTIGhlYWRpbmdzOiBPQU0gb2YgRmF1bHRz LCBDb25maWd1cmF0aW9uLCBBY2NvdW50aW5nLCBQZXJmb3JtYW5jZQ0KICAgYW5kIFNlY3VyaXR5 Lg0KDQo3LjEuICBGYXVsdCBPQU0NCg0KICAgRmF1bHQgT0FNIGlzIGFib3V0IGhvdyB0byB0ZWxs IHRoZSBtYW5hZ2VtZW50IHN5c3RlbSAob3IgbWFudWFsDQogICBvcGVyYXRvcikgdGhhdCB0aGUg c3lzdGVtIGhhcyByZWNvdmVyZWQgKG9yIG5vdCkgZnJvbSBhIGZhaWx1cmUuDQoNCiAgIEZhdWx0 cyBpbmNsdWRlIG5vZGUgb3IgbGluayBmYWlsdXJlcywgYSB3cm9uZ2x5IGNvbmZpZ3VyZWQgYWRk cmVzcyBpbg0KICAgYSBub2RlLCBhIHdyb25nIGFkZHJlc3MgZ2l2ZW4gaW4gYSBzaWduYWxsaW5n IHByb3RvY29sLCBhIHdyb25nbHkNCiAgIGNvbmZpZ3VyZWQgcGFyYW1ldGVyIGluIGEgcXVldWVp bmcgYWxnb3JpdGhtLCBhbmQgc28gb24uDQoNCjcuMi4gIENvbmZpZ3VyYXRpb24gT0FNDQoNCiAg IFBlcmhhcHMgdGhlIG1vc3QgaW1wb3J0YW50IGNvbnNpZGVyYXRpb24gaGVyZSBpcyB0aGF0IHRo ZSBsZXZlbCBvZg0KICAgZGV0YWlsIG9mIHRoZSBzdGFuZGFyZGlzYXRpb24gYWZmZWN0cyB3aGF0 IGNhbiBiZSBjb25maWd1cmVkLiAgV2UNCiAgIHdvdWxkIGxpa2UgZGlmZmVyZW50IGltcGxlbWVu dGF0aW9ucyBhbmQgY29uZmlndXJhdGlvbnMgKGVnIGNob2ljZSBvZg0KICAgcGFyYW1ldGVycykg dGhhdCBhcmUgY29tcGxpYW50IHdpdGggdGhlIFBDTiBzdGFuZGFyZCB0byB3b3JrIHRvZ2V0aGVy DQogICBzdWNjZXNzZnVsbHkuDQoNCiAgIE9idmlvdXMgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJz IGFyZSB0aGUgUENOLWxvd2VyLXJhdGUgYW5kIFBDTi0NCiAgIHVwcGVyLXJhdGUuICBBIGxhcmdl ciBQQ04tbG93ZXItcmF0ZSBlbmFibGVzIG1vcmUgUENOLXRyYWZmaWMgdG8gYmUNCiAgIGFkbWl0 dGVkIG9uIGEgbGluaywgaGVuY2UgaW1wcm92aW5nIGNhcGFjaXR5IHV0aWxpc2F0aW9uLiAgQSBQ Q04tDQogICB1cHBlci1yYXRlIHNldCBmdXJ0aGVyIGFib3ZlIHRoZSBQQ04tbG93ZXItcmF0ZSBh bGxvd3MgZ3JlYXRlcg0KICAgaW5jcmVhc2VzIGluIHRyYWZmaWMgKHdoZXRoZXIgZHVlIHRvIG5h dHVyYWwgZmx1Y3R1YXRpb25zIG9yIHNvbWUNCg0KDQoNCkVhcmRsZXkgKEVkaXRvcikgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDIzXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDA3DQoNCg0KICAgdW5leHBlY3RlZCBldmVudCkgYmVmb3JlIGFueSBmbG93cyBh cmUgdGVybWluYXRlZCwgaWUgbWluaW1pc2VzIHRoZQ0KICAgY2hhbmNlcyBvZiB1bm5lY2Vzc2Fy aWx5IHRyaWdnZXJpbmcgdGhlIHRlcm1pbmF0aW9uIG1lY2hhbmlzbS4gIEENCiAgIGdyZWF0ZXIg Z2FwLCBiZXR3ZWVuIHRoZSBtYXhpbXVtIHJhdGUgYXQgd2hpY2ggUENOLXRyYWZmaWMgY2FuIGJl DQogICBmb3J3YXJkZWQgb24gYSBsaW5rIGFuZCB0aGUgUENOLWxvd2VyLXJhdGUgYW5kIFBDTi11 cHBlci1yYXRlLA0KICAgaW5jcmVhc2VzIHRoZSAnc2FmZXR5IG1hcmdpbicgLSB3aGljaCBjYW4g Y292ZXIgdW5leHBlY3RlZCBzdXJnZXMgaW4NCiAgIHRyYWZmaWMgZHVlIHRvIGEgcmUtcm91dGlu ZyBldmVudCBmb3IgaW5zdGFuY2UuICBGb3IgaW5zdGFuY2UgYW4NCiAgIG9wZXJhdG9yIG1heSB3 YW50IHRvIGRlc2lnbiB0aGVpciBuZXR3b3JrIHNvIHRoYXQgaXQgY2FuIGNvcGUgd2l0aCBhDQog ICBmYWlsdXJlIG9mIGFueSBzaW5nbGUgUENOLW5vZGUgd2l0aG91dCB0ZXJtaW5hdGluZyBhbnkg Zmxvd3MuDQogICBTZXR0aW5nIHRoZSByYXRlcyB3aWxsIHRoZXJlZm9yZSBkZXBlbmQgb24gdGhp bmdzIGxpa2U6IHRoZQ0KICAgb3BlcmF0b3IncyByZXF1aXJlbWVudHMsIHRoZSBsaW5rJ3MgY2Fw YWNpdHksIHRoZSB0eXBpY2FsIG51bWJlciBvZg0KICAgZmxvd3MgYW5kIHBlcmhhcHMgdGhlaXIg dHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3MsIGFuZCBzbyBvbi4NCg0KICAgT3RoZXIgY29uZmlndXJh YmxlIHBhcmFtZXRlcnMgY29uY2VybiB0aGUgUENOLWJvdW5kYXJ5LW5vZGVzLiAgRm9yDQogICBl eGFtcGxlLCB0aGUgYW1vdW50IG9mIFBDTi1tYXJrZWQgdHJhZmZpYyBhYm92ZSB3aGljaCBuZXcg Zmxvd3MgYXJlDQogICBibG9ja2VkLg0KDQogICBBbm90aGVyIGNvbmZpZ3VyYXRpb24gY2hvaWNl IGlzIHRoZSBkaXN0cmlidXRpb24gb2YgdGhlIGZ1bmN0aW9ucw0KICAgY29uY2VybmluZyBmbG93 cyBhZG1pc3Npb24gYW5kIHRlcm1pbmF0aW9uLCBnaXZlbiBpbiBTZWN0aW9uIDUuNCBhbmQNCiAg IDUuNiwgYW5kIHdoaWNoIGNvdWxkIHBvdGVudGlhbGx5IGJlIHVuZGVyIHRoZSBjb250cm9sIG9m IGENCiAgIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyLg0KDQogICBBbm90aGVyIGNvbmZpZ3VyYXRp b24gZGVjaXNpb24gaXMgd2hldGhlciB0byBvcGVyYXRlIGJvdGggdGhlDQogICBhZG1pc3Npb24g Y29udHJvbCBhbmQgdGVybWluYXRpb24gbWVjaGFuaXNtcy4gIEFsdGhvdWdoIHdlIHN1Z2dlc3QN CiAgIHRoYXQgYW4gb3BlcmF0b3IgdXNlcyBib3RoLCB0aGlzIGlzbid0IHJlcXVpcmVkIGFuZCBz b21lIG9wZXJhdG9ycw0KICAgbWF5IHdhbnQgdG8gaW1wbGVtZW50IG9ubHkgb25lLiAgRm9yIGV4 YW1wbGUsIGFuIG9wZXJhdG9yIGNvdWxkIHVzZQ0KICAganVzdCBhZG1pc3Npb24gY29udHJvbCwg c29sdmluZyBoZWF2eSBjb25nZXN0aW9uIChjYXVzZWQgYnkgcmUtDQogICByb3V0aW5nKSBieSAn anVzdCB3YWl0aW5nJyAtIGFzIHNlc3Npb25zIGVuZCwgZXhpc3RpbmcgbWljcm9mbG93cw0KICAg bmF0dXJhbGx5IGRlcGFydCBmcm9tIHRoZSBzeXN0ZW0gb3ZlciB0aW1lLCBhbmQgdGhlIGFkbWlz c2lvbiBjb250cm9sDQogICBtZWNoYW5pc20gd2lsbCBwcmV2ZW50IGFkbWlzc2lvbiBvZiBuZXcg bWljcm9mbG93cyB0aGF0IHVzZSB0aGUNCiAgIGFmZmVjdGVkIGxpbmtzLiAgU28gdGhlIFBDTi1k b21haW4gd2lsbCBuYXR1cmFsbHkgcmV0dXJuIHRvIG5vcm1hbA0KICAgb3BlcmF0aW9uLCBidXQg d2l0aCByZWR1Y2VkIGNhcGFjaXR5LiAgVGhlIGRyYXdiYWNrIG9mIHRoaXMgYXBwcm9hY2gNCiAg IHdvdWxkIGJlIHRoYXQgdW50aWwgUENOLWZsb3dzIG5hdHVyYWxseSBkZXBhcnQgdG8gcmVsaWV2 ZSB0aGUNCiAgIGNvbmdlc3Rpb24sIGFsbCBQQ04tZmxvd3MgYXMgd2VsbCBhcyBsb3dlciBwcmlv cml0eSBzZXJ2aWNlcyB3aWxsIGJlDQogICBhZHZlcnNlbHkgYWZmZWN0ZWQuICBPbiB0aGUgb3Ro ZXIgaGFuZCwgYW4gb3BlcmF0b3IgY291bGQganVzdCByZWx5DQogICBmb3IgYWRtaXNzaW9uIGNv bnRyb2wgb24gc3RhdGljYWxseSBwcm92aXNpb25lZCBjYXBhY2l0eSBwZXIgUENOLQ0KICAgaW5n cmVzcy1ub2RlIChyZWdhcmRsZXNzIG9mIHRoZSBQQ04tZWdyZXNzLW5vZGUgb2YgYSBmbG93KSwg YXMgaXMNCiAgIHR5cGljYWwgaW4gdGhlIGhvc2UgbW9kZWwgb2YgdGhlIERpZmZTZXJ2IGFyY2hp dGVjdHVyZSBbUkZDMjQ3NV0uDQogICBTdWNoIHRyYWZmaWMgY29uZGl0aW9uaW5nIGFncmVlbWVu dHMgY2FuIGxlYWQgdG8gZm9jdXNlZCBvdmVybG9hZDoNCiAgIG1hbnkgZmxvd3MgaGFwcGVuIHRv IGZvY3VzIG9uIGEgcGFydGljdWxhciBsaW5rIGFuZCB0aGVuIGFsbCBmbG93cw0KICAgdGhyb3Vn aCB0aGUgY29uZ2VzdGVkIGxpbmsgZmFpbCBjYXRhc3Ryb3BoaWNhbGx5LiAgVGhlIGZsb3cNCiAg IHRlcm1pbmF0aW9uIG1lY2hhbmlzbSBjb3VsZCB0aGVuIGJlIHVzZWQgdG8gY291bnRlcmFjdCBz dWNoIGENCiAgIHByb2JsZW0uDQoNCiAgIEEgZGlmZmVyZW50IHBvc3NpYmlsaXR5IGlzIHRvIGNv bmZpZ3VyZSBvbmx5IHRoZSBQQ04tbG93ZXItcmF0ZSBhbmQNCiAgIGhlbmNlIG9ubHkgZG8gb25l IHR5cGUgb2YgUENOLW1hcmtpbmcsIGJ1dCBnZW5lcmF0ZSBhZG1pc3Npb24gYW5kDQogICBmbG93 IHRlcm1pbmF0aW9uIHJlc3BvbnNlcyBmcm9tIGRpZmZlcmVudCBsZXZlbHMgb2YgbWFya2luZy4g IFRoaXMgaXMNCiAgIHN1Z2dlc3RlZCBpbiBbSS1ELmNoYXJueS1wY24tc2luZ2xlLW1hcmtpbmdd IHdoaWNoIGdpdmVzIHNvbWUgb2YgdGhlDQogICBwcm9zIGFuZCBjb25zIG9mIHRoaXMgYXBwcm9h Y2guDQoNCg0KDQpFYXJkbGV5IChFZGl0b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDksIDIw MDggICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgRG9jdW1lbnQgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIEFu b3RoZXIgUENOIFdHIGRvY3VtZW50IHdpbGwgc3BlY2lmeSBQQ04tbWFya2luZywgaW4gcGFydGlj dWxhciBob3cNCiAgIG1hbnkgUENOLXBhY2tldHMgZ2V0IFBDTi1tYXJrZWQgYWNjb3JkaW5nIHRv IHdoYXQgbWVhc3VyZSBvZiBQQ04tDQogICB0cmFmZmljLiAgRm9yIGluc3RhbmNlIGFuIGFsZ29y aXRobSByZWxhdGluZyB0aGUgY3VycmVudCByYXRlIG9mIFBDTi0NCiAgIHRyYWZmaWMgdG8gdGhl IHByb2JhYmlsaXR5IG9mIGFkbWlzc2lvbi1tYXJraW5nIGEgcGFja2V0LiAgRGVwZW5kaW5nDQog ICBvbiBob3cgdGlnaHRseSBpdCBpcyBkZWNpZGVkIHRvIHNwZWNpZnkgdGhpcywgdGhlcmUgYXJl IHBvdGVudGlhbGx5DQogICBxdWl0ZSBhIGZldyBjb25maWd1cmF0aW9uIGNob2ljZXMsIGZvciBp bnN0YW5jZToNCg0KICAgbyAgZG9lcyB0aGUgcHJvYmFiaWxpdHkgZ28gZnJvbSAwJSBhdCBvbmUg cmF0ZSBvZiBQQ04tdHJhZmZpYyAodGhlDQogICAgICBQQ04tbG93ZXItcmF0ZSkgdG8gMTAwJSBh dCBhIHNsaWdodGx5IGhpZ2hlciByYXRlIChpZSB0aHJlc2hvbGQtDQogICAgICBtYXJraW5nKSwg b3IgZG9lcyBpdCAncmFtcCB1cCcgZ3JhZHVhbGx5IChhcyBpbiBSRUQpPyAgRG9lcyB0aGUNCiAg ICAgIHN0YW5kYXJkIGFsbG93IGJvdGg/DQoNCiAgIG8gIGhvdyBpcyB0aGUgY3VycmVudCByYXRl IG9mIFBDTi10cmFmZmljIG1lYXN1cmVkPyAgUmF0ZSBjYW5ub3QgYmUNCiAgICAgIG1lYXN1cmVk IGluc3RhbnRhbmVvdXNseSwgc28gaG93IGlzIHRoaXMgc21vb3RoZWQ/ICBBIHNsaWRpbmcNCiAg ICAgIHdpbmRvdyBvciBleHBvbmVudGlhbGx5IHdlaWdodGVkIG1vdmluZyBhdmVyYWdlPw0KDQog ICBvICBpcyB0aGUgUENOLWxvd2VyLXJhdGUgYSBmaXhlZCBwYXJhbWV0ZXI/ICBBbiBpZGVhIHJh aXNlZCBpbg0KICAgICAgW1NvbmdodXJzdF0gaXMgdGhhdCB0aGUgUENOLWxvd2VyLXJhdGUgb24g ZWFjaCByb3V0ZXIgc2hvdWxkDQogICAgICBkZXBlbmQgb24gdGhlIGN1cnJlbnQgYW1vdW50IG9m IG5vbi1QQ04tdHJhZmZpYzsgdGhlIGFpbSBpcyB0aGF0DQogICAgICByZXNvdXJjZSBhbGxvY2F0 aW9uIHJlZmxlY3RzIHRoZSB0cmFmZmljIG1peCAtIGZvciBpbnN0YW5jZSBtb3JlDQogICAgICBQ Q04tdHJhZmZpYyBjb3VsZCBiZSBhZG1pdHRlZCBpZiB0aGUgZnJhY3Rpb24gb2YgUENOLXRyYWZm aWMgd2FzDQogICAgICBoaWdoZXIuICBJcyB0aGlzIGFsbG93ZWQ/DQoNCiAgIEFub3RoZXIgcXVl c3Rpb24gaXMgd2hldGhlciB0aGVyZSBhcmUgYW55IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycw0K ICAgdGhhdCBoYXZlIHRvIGJlIHNldCBvbmNlIHRvICdnbG9iYWxseScgY29udHJvbCB0aGUgd2hv bGUgUENOLWRvbWFpbg0KICAgKGFzIHJlcXVpcmVkIGJ5IHNvbWUgcHJvcG9zYWxzKS4gIFRoaXMg bWF5IGFmZmVjdCBvcGVyYXRpb25hbA0KICAgY29tcGxleGl0eSBhbmQgdGhlIGNoYW5jZXMgb2Yg aW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBiZXR3ZWVuIGtpdA0KICAgZnJvbSBkaWZmZXJlbnQg dmVuZG9ycy4NCg0KNy4zLiAgQWNjb3VudGluZyBPQU0NCg0KICAgQWNjb3VudGluZyBhdCB0aGUg ZmxvdyBsZXZlbCB3aWxsIGhhdmUgdG8gcmVjb3JkIGluc3RhbmNlcyBvZiBmbG93DQogICBhZG1p c3Npb24sIHJlamVjdGlvbiBhbmQgdGVybWluYXRpb24sIGJ1dCBhY2NvdW50aW5nIGl0c2VsZiBp cw0KICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgUENOLiAgVGhlIGFiaWxpdHkgdG8gZW5hYmxlIG9y IGRpc2FibGUgZmxvdw0KICAgYWNjb3VudGluZyBmb3Igc3BlY2lmaWMgY2xhc3NlcyBvZiBmbG93 IGFuZCB0byBzcGVjaWZ5IHJldHJpZXZhbCBvZg0KICAgYWNjb3VudGluZyByZWNvcmRzIGluIHJl YWwgdGltZSBmb3Igc3BlY2lmaWVkIGNsYXNzZXMgb2YgZmxvdyBpcyBhDQogICBnZW5lcmFsIHJl cXVpcmVtZW50IG5vdCBzcGVjaWZpYyB0byBQQ04gdGhhdCBtYXksIGhvd2V2ZXIsIGZpbmQNCiAg IHNwZWNpZmljIHVzZSB3aGVuIGRpYWdub3NpbmcgZmF1bHRzIGFmZmVjdGluZyBQQ04gb3BlcmF0 aW9uLg0KDQo3LjQuICBQZXJmb3JtYW5jZSBPQU0NCg0KICAgUGVyZm9ybWFuY2UgT0FNIGlzIGFi b3V0IG1vbml0b3JpbmcgcGVyZm9ybWFuY2UgYXQgcnVuLXRpbWUuICBUaGVyZQ0KICAgYXJlIGEg d2lkZSB2YXJpZXR5IG9mIHBlcmZvcm1hbmNlIG1ldHJpY3MgdGhhdCBpdCBtYXkgYmUgd29ydGgN CiAgIGNvbGxlY3RpbmcgYXQgUENOLWluZ3Jlc3Mtbm9kZXMsIFBDTi1lZ3Jlc3Mtbm9kZXMgYW5k IFBDTi1pbnRlcmlvci0NCiAgIG5vZGVzLiAgQSBkZXRhaWxlZCBsaXN0IG9mIG1ldHJpY3MgaXMg bm90IHBhcnQgb2YgdGhpcyBhcmNoaXRlY3R1cmUNCiAgIGRvY3VtZW50LCBidXQgdGhlIHNvcnRz IG9mIHRoaW5ncyB3b3VsZCBiZToNCg0KDQoNCg0KDQpFYXJkbGV5IChFZGl0b3IpICAgICAgICBF eHBpcmVzIEZlYnJ1YXJ5IDksIDIwMDggICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgRG9jdW1lbnQgICAgICAgICAgICAgICAgICAgICBB dWd1c3QgMjAwNw0KDQoNCiAgIG8gIGNhbiB0aGUgb3BlcmF0b3IgaWRlbnRpZnkgJ2hvdCBzcG90 cycgaW4gdGhlIG5ldHdvcmsgKGxpbmtzIHdoaWNoDQogICAgICBtb3N0IG9mdGVuIGRvIFBDTi1t YXJraW5nKT8gIFRoaXMgd291bGQgaGVscCB0aGVtIHBsYW4gdG8gaW5zdGFsbA0KICAgICAgZXh0 cmEgY2FwYWNpdHkgd2hlcmUgaXQgaXMgbW9zdCBuZWVkZWQuDQoNCiAgIG8gIHdoYXQgaXMgdGhl IHJhdGUgYXQgd2hpY2ggZmxvd3MgYXJlIGFkbWl0dGVkIGFuZCB0ZXJtaW5hdGVkIChmb3INCiAg ICAgIGVhY2ggcGFpciBvZiBQQ04tYm91bmRhcnktbm9kZXMpPyAgU3VjaCBpbmZvcm1hdGlvbiB3 b3VsZCBiZQ0KICAgICAgdXNlZnVsIGZvciBmYXVsdCBtYW5hZ2VtZW50LCBuZXR3b3JraW5nIHBs YW5uaW5nIGFuZCBzZXJ2aWNlIGxldmVsDQogICAgICBtb25pdG9yaW5nLg0KDQo3LjUuICBTZWN1 cml0eSBPQU0NCg0KICAgU2VjdXJpdHkgT0FNIGlzIGZpbmRpbmcgb3V0IGFib3V0IHNlY3VyaXR5 IGJyZWFjaGVzIG9yIG5lYXItbWlzc2VzIGF0DQogICBydW4tdGltZS4NCg0KDQo4LiAgSUFOQSBD b25zaWRlcmF0aW9ucw0KDQogICBUaGlzIG1lbW8gaW5jbHVkZXMgbm8gcmVxdWVzdCB0byBJQU5B Lg0KDQoNCjkuICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KDQogICBTZWN1cml0eSBjb25zaWRl cmF0aW9ucyBlc3NlbnRpYWxseSBjb21lIGZyb20gdGhlIFRydXN0IEFzc3VtcHRpb24NCiAgIChT ZWN0aW9uIDMuMSksIGllIHRoYXQgYWxsIFBDTi1ub2RlcyBhcmUgUENOLWVuYWJsZWQgYW5kIHRy dXN0IGVhY2gNCiAgIG90aGVyIGZvciB0cnV0aGZ1bCBQQ04tbWFya2luZyBhbmQgdHJhbnNwb3J0 LiAgUENOIHNwbGl0cw0KICAgZnVuY3Rpb25hbGl0eSBiZXR3ZWVuIFBDTi1pbnRlcmlvci1ub2Rl cyBhbmQgUENOLWJvdW5kYXJ5LW5vZGVzLCBhbmQNCiAgIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBhcmUgc29tZXdoYXQgZGlmZmVyZW50IGZvciBlYWNoLCBtYWlubHkNCiAgIGJlY2F1c2Ug UENOLWJvdW5kYXJ5LW5vZGVzIGFyZSBmbG93LWF3YXJlIGFuZCBQQ04taW50ZXJpb3Itbm9kZXMg YXJlDQogICBub3QuDQoNCiAgIG8gIGJlY2F1c2UgdGhlIFBDTi1ib3VuZGFyeS1ub2RlcyBhcmUg Zmxvdy1hd2FyZSwgdGhleSBhcmUgdHJ1c3RlZCB0bw0KICAgICAgdXNlIHRoYXQgYXdhcmVuZXNz IGNvcnJlY3RseS4gIFRoZSBkZWdyZWUgb2YgdHJ1c3QgcmVxdWlyZWQNCiAgICAgIGRlcGVuZHMg b24gdGhlIGtpbmRzIG9mIGRlY2lzaW9ucyB0aGV5IGhhdmUgdG8gbWFrZSBhbmQgdGhlIGtpbmRz DQogICAgICBvZiBpbmZvcm1hdGlvbiB0aGV5IG5lZWQgdG8gbWFrZSB0aGVtLiAgRm9yIGV4YW1w bGUgd2hlbiB0aGUgUENOLQ0KICAgICAgYm91bmRhcnktbm9kZSBuZWVkcyB0byBrbm93IHRoZSBj b250ZW50cyBvZiB0aGUgc2Vzc2lvbnMgZm9yDQogICAgICBtYWtpbmcgdGhlIGFkbWlzc2lvbiBh bmQgdGVybWluYXRpb24gZGVjaXNpb25zIChwZXJoYXBzIGJhc2VkIG9uDQogICAgICB0aGUgTUxQ UCBwcmVjZWRlbmNlKSwgb3Igd2hlbiB0aGUgY29udGVudHMgYXJlIGhpZ2hseSBjbGFzc2lmaWVk LA0KICAgICAgdGhlbiB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciB0aGUgUENOLWJvdW5k YXJ5LW5vZGVzIGludm9sdmVkDQogICAgICB3aWxsIGFsc28gbmVlZCB0byBiZSBoaWdoLg0KDQog ICBvICB0aGUgUENOLWluZ3Jlc3Mtbm9kZXMgcG9saWNlIHBhY2tldHMgdG8gZW5zdXJlIGEgZmxv dyBzdGlja3MNCiAgICAgIHdpdGhpbiBpdHMgYWdyZWVkIGxpbWl0LCBhbmQgdG8gZW5zdXJlIHRo YXQgb25seSBmbG93cyB3aGljaCBoYXZlDQogICAgICBiZWVuIGFkbWl0dGVkIGNvbnRyaWJ1dGUg UENOLXRyYWZmaWMgaW50byB0aGUgUENOLWRvbWFpbi4gIFRoZQ0KICAgICAgcG9saWNlciBtdXN0 IGRyb3AgKG9yIHBlcmhhcHMgcmUtbWFyayB0byBhIGRpZmZlcmVudCBEU0NQKSBhbnkNCiAgICAg IFBDTi1wYWNrZXRzIHJlY2VpdmVkIHRoYXQgYXJlIG91dHNpZGUgdGhpcyByZW1pdC4gIFRoaXMg aXMgc2ltaWxhcg0KICAgICAgdG8gdGhlIGV4aXN0aW5nIEludFNlcnYgYmVoYXZpb3VyLiAgQmV0 d2VlbiB0aGVtIHRoZSBQQ04tYm91bmRhcnktDQogICAgICBub2RlcyBtdXN0IGVuY2lyY2xlIHRo ZSBQQ04tZG9tYWluLCBvdGhlcndpc2UgUENOLXBhY2tldHMgY291bGQNCiAgICAgIGVudGVyIHRo ZSBQQ04tZG9tYWluIHdpdGhvdXQgYmVpbmcgc3ViamVjdCB0byBhZG1pc3Npb24gY29udHJvbCwN Cg0KDQoNCkVhcmRsZXkgKEVkaXRvcikgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgOSwgMjAwOCAg ICAgICAgICAgICAgIFtQYWdlIDI2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICBEb2N1bWVudCAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAgICAgd2hp Y2ggd291bGQgcG90ZW50aWFsbHkgZGVzdHJveSB0aGUgUW9TIG9mIGV4aXN0aW5nIGZsb3dzLg0K DQogICBvICBQQ04taW50ZXJpb3Itbm9kZXMgYXJlbid0IGZsb3ctYXdhcmUuICBUaGlzIHByZXZl bnRzIHNvbWUgc2VjdXJpdHkNCiAgICAgIGF0dGFja3Mgd2hlcmUgYW4gYXR0YWNrZXIgdGFyZ2V0 cyBzcGVjaWZpYyBmbG93cyBpbiB0aGUgZGF0YSBwbGFuZQ0KICAgICAgLSBmb3IgaW5zdGFuY2Ug Zm9yIERvUyBvciBlYXZlc2Ryb3BwaW5nLg0KDQogICBvICBQQ04tbWFya2luZyBieSB0aGUgUENO LWludGVyaW9yLW5vZGVzIGFsb25nIHRoZSBwYWNrZXQgZm9yd2FyZGluZw0KICAgICAgcGF0aCBu ZWVkcyB0byBiZSB0cnVzdGVkLCBiZWNhdXNlIHRoZSBQQ04tYm91bmRhcnktbm9kZXMgcmVseSBv bg0KICAgICAgdGhpcyBpbmZvcm1hdGlvbi4gIEZvciBpbnN0YW5jZSBhIHJvZ3VlIFBDTi1pbnRl cmlvci1ub2RlIGNvdWxkDQogICAgICBQQ04tbWFyayBhbGwgcGFja2V0cyBzbyB0aGF0IG5vIGZs b3dzIHdlcmUgYWRtaXR0ZWQuICBBbm90aGVyDQogICAgICBwb3NzaWJpbGl0eSBpcyB0aGF0IGl0 IGRvZXNuJ3QgUENOLW1hcmsgYW55IHBhY2tldHMsIGV2ZW4gd2hlbg0KICAgICAgaXQncyBwcmUt Y29uZ2VzdGVkLiAgTW9yZSBzdWJ0bHksIHRoZSByb2d1ZSBQQ04taW50ZXJpb3Itbm9kZQ0KICAg ICAgY291bGQgcGVyZm9ybSB0aGVzZSBhdHRhY2tzIHNlbGVjdGl2ZWx5IG9uIHBhcnRpY3VsYXIg Zmxvd3MsIG9yIGl0DQogICAgICBjb3VsZCBQQ04tbWFyayB0aGUgY29ycmVjdCBmcmFjdGlvbiBv dmVyYWxsLCBidXQgY2FyZWZ1bGx5IGNob29zZQ0KICAgICAgd2hpY2ggZmxvd3MgaXQgbWFya2Vk Lg0KDQogICBvICB0aGUgUENOLWJvdW5kYXJ5LW5vZGVzIHNob3VsZCBiZSBhYmxlIHRvIGRlYWwg d2l0aCBEb1MgYXR0YWNrcyBhbmQNCiAgICAgIHN0YXRlIGV4aGF1c3Rpb24gYXR0YWNrcyBiYXNl ZCBvbiBmYXN0IGNoYW5nZXMgaW4gcGVyIGZsb3cNCiAgICAgIHNpZ25hbGxpbmcuDQoNCiAgIG8g IHRoZSBzaWduYWxsaW5nIGJldHdlZW4gdGhlIFBDTi1ib3VuZGFyeS1ub2RlcyAoYW5kIHBvc3Np Ymx5IGENCiAgICAgIGNlbnRyYWwgY29udHJvbCBub2RlKSBtdXN0IGJlIHByb3RlY3RlZCBmcm9t IGF0dGFja3MuICBGb3IgZXhhbXBsZQ0KICAgICAgdGhlIHJlY2lwaWVudCBuZWVkcyB0byB2YWxp ZGF0ZSB0aGF0IHRoZSBtZXNzYWdlIGlzIGluZGVlZCBmcm9tDQogICAgICB0aGUgbm9kZSB0aGF0 IGNsYWltcyB0byBoYXZlIHNlbnQgaXQuICBQb3NzaWJsZSBtZWFzdXJlcyBpbmNsdWRlDQogICAg ICBkaWdlc3QgYXV0aGVudGljYXRpb24gYW5kIHByb3RlY3Rpb24gYWdhaW5zdCByZXBsYXkgYW5k IG1hbi1pbi0NCiAgICAgIHRoZS1taWRkbGUgYXR0YWNrcy4gIEZvciB0aGUgc3BlY2lmaWMgcHJv dG9jb2wgUlNWUCwgaG9wLWJ5LWhvcA0KICAgICAgYXV0aGVudGljYXRpb24gaXMgaW4gW1JGQzI3 NDddLCBhbmQNCiAgICAgIFtJLUQuYmVocmluZ2VyLXRzdndnLXJzdnAtc2VjdXJpdHktZ3JvdXBr ZXlpbmddIG1heSBhbHNvIGJlDQogICAgICB1c2VmdWw7IGZvciBhIGdlbmVyaWMgc2lnbmFsbGlu ZyBwcm90b2NvbCB0aGUgUENOIFdHIGRvY3VtZW50IG9uDQogICAgICAiUmVxdWlyZW1lbnRzIGZv ciBzaWduYWxsaW5nIiB3aWxsIGRlc2NyaWJlIHRoZSByZXF1aXJlbWVudHMgaW4NCiAgICAgIG1v cmUgZGV0YWlsLg0KDQoNCjEwLiAgQ29uY2x1c2lvbnMNCg0KICAge1RvRG86fQ0KDQoNCjExLiAg QWNrbm93bGVkZ2VtZW50cw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGEgcmV2aXNlZCB2ZXJzaW9u IG9mIFtJLUQuZWFyZGxleS1wY24tYXJjaGl0ZWN0dXJlXS4NCiAgIEl0cyBhdXRob3JzIHdlcmU6 IFAuIEVhcmRsZXksIEouIEJhYmlhcnosIEsuIENoYW4sIEEuIENoYXJueSwgUi4NCiAgIEdlaWIs IEcuIEthcmFnaWFubmlzLCBNLiBNZW50aCwgVC4gVHNvdS4gIFRoZXkgYXJlIHRoZXJlZm9yZQ0K ICAgY29udHJpYnV0b3JzIHRvIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFRoYW5rcyB0byB0aG9zZSB3 aG8ndmUgbWFkZSBjb21tZW50cyBvbg0KICAgW0ktRC5lYXJkbGV5LXBjbi1hcmNoaXRlY3R1cmVd OiBCb2IgQnJpc2NvZSwgTWljaGFlbCBNZW50aCwgTGFycw0KICAgRWdnZXJ0LCBTdGV2ZW4gQmxh a2UsIFRpbmEgVHNvdSwgVG9tIFRheWxvciwgUnVlZGlnZXIgR2VpYiwgSm9lDQoNCg0KDQpFYXJk bGV5IChFZGl0b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDksIDIwMDggICAgICAgICAgICAg ICBbUGFnZSAyN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgRG9jdW1lbnQg ICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCiAgIEJhYmlhcnosIEFubmEgQ2hh cm55LCBKb2FjaGltIENoYXJ6aW5za2ksIEdlb3JnaW9zIEthcmFnaWFubmlzLg0KDQogICBUaGlz IGRvY3VtZW50IGlzIHRoZSByZXN1bHQgb2YgZGlzY3Vzc2lvbnMgaW4gdGhlIFBDTiBXRyBhbmQN CiAgIGZvcmVydW5uZXIgYWN0aXZpdHkgaW4gdGhlIFRTVldHLiAgQSBudW1iZXIgb2YgcHJldmlv dXMgZHJhZnRzIHdlcmUNCiAgIHByZXNlbnRlZCB0byBUU1ZXRzogW0ktRC5jaGFuLXBjbi1wcm9i bGVtLXN0YXRlbWVudF0sDQogICBbSS1ELmJyaXNjb2UtdHN2d2ctY2wtYXJjaGl0ZWN0dXJlXSwg W0ktRC5icmlzY29lLXRzdndnLWNsLXBoYl0sDQogICBbSS1ELmNoYXJueS1wY24tc2luZ2xlLW1h cmtpbmddLCBbSS1ELmJhYmlhcnotcGNuLXNpcC1jYXBdLA0KICAgW0ktRC5sZWZhdWNoZXVyLXJz dnAtZWNuXS4gIFRoZSBhdXRob3JzIG9mIHRoZW0gd2VyZTogQiwgQnJpc2NvZSwgUC4NCiAgIEVh cmRsZXksIEQuIFNvbmdodXJzdCwgRi4gTGUgRmF1Y2hldXIsIEEuIENoYXJueSwgSi4gQmFiaWFy eiwgSy4NCiAgIENoYW4sIFMuIER1ZGxleSwgRy4gS2FyYWdpYW5uaXMsIEEuIEJhZGVyLCBMLiBX ZXN0YmVyZywgSi4gWmhhbmcsIFYuDQogICBMaWF0c29zLCBYLUcuICBMaXUuDQoNCg0KMTIuICBD b21tZW50cyBTb2xpY2l0ZWQNCg0KICAgQ29tbWVudHMgYW5kIHF1ZXN0aW9ucyBhcmUgZW5jb3Vy YWdlZCBhbmQgdmVyeSB3ZWxjb21lLiAgVGhleSBjYW4gYmUNCiAgIGFkZHJlc3NlZCB0byB0aGUg SUVURiBQQ04gd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgPHBjbkBpZXRmLm9yZz4uDQoNCg0K MTMuICBSZWZlcmVuY2VzDQoNCjEzLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZD MjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0 ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBN YXJjaCAxOTk3Lg0KDQoxMy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbSS1ELmJy aXNjb2UtdHN2d2ctY2wtYXJjaGl0ZWN0dXJlXQ0KICAgICAgICAgICAgICBCcmlzY29lLCBCLiwg IkFuIGVkZ2UtdG8tZWRnZSBEZXBsb3ltZW50IE1vZGVsIGZvciBQcmUtDQogICAgICAgICAgICAg IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uOiBBZG1pc3Npb24gIENvbnRyb2wgb3ZlciBhDQogICAg ICAgICAgICAgIERpZmZTZXJ2IFJlZ2lvbiIsIGRyYWZ0LWJyaXNjb2UtdHN2d2ctY2wtYXJjaGl0 ZWN0dXJlLTA0DQogICAgICAgICAgICAgICh3b3JrIGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDA2 Lg0KDQogICBbSS1ELmJyaXNjb2UtdHN2d2ctY2wtcGhiXQ0KICAgICAgICAgICAgICBCcmlzY29l LCBCLiwgIlByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiBtYXJraW5nIiwNCiAgICAgICAgICAg ICAgZHJhZnQtYnJpc2NvZS10c3Z3Zy1jbC1waGItMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLA0KICAg ICAgICAgICAgICBPY3RvYmVyIDIwMDYuDQoNCiAgIFtJLUQuY2hhcm55LXBjbi1zaW5nbGUtbWFy a2luZ10NCiAgICAgICAgICAgICAgQ2hhcm55LCBBLiwgIlByZS1Db25nZXN0aW9uIE5vdGlmaWNh dGlvbiBVc2luZyBTaW5nbGUNCiAgICAgICAgICAgICAgTWFya2luZyBmb3IgQWRtaXNzaW9uIGFu ZCAgVGVybWluYXRpb24iLA0KICAgICAgICAgICAgICBkcmFmdC1jaGFybnktcGNuLXNpbmdsZS1t YXJraW5nLTAyICh3b3JrIGluIHByb2dyZXNzKSwNCiAgICAgICAgICAgICAgSnVseSAyMDA3Lg0K DQogICBbSS1ELmlldGYtdHN2d2ctYWRtaXR0ZWQtcmVhbHRpbWUtZHNjcF0NCiAgICAgICAgICAg ICAgQmFrZXIsIEYuLCAiRFNDUHMgZm9yIENhcGFjaXR5LUFkbWl0dGVkIFRyYWZmaWMiLA0KICAg ICAgICAgICAgICBkcmFmdC1pZXRmLXRzdndnLWFkbWl0dGVkLXJlYWx0aW1lLWRzY3AtMDEgKHdv cmsgaW4NCg0KDQoNCkVhcmRsZXkgKEVkaXRvcikgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgOSwg MjAwOCAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICBEb2N1bWVudCAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA3DQoNCg0KICAg ICAgICAgICAgICBwcm9ncmVzcyksIE1hcmNoIDIwMDcuDQoNCiAgIFtJLUQuYmFiaWFyei1wY24t c2lwLWNhcF0NCiAgICAgICAgICAgICAgQmFiaWFyeiwgSi4sICJTSVAgQ29udHJvbGxlZCBBZG1p c3Npb24gYW5kIFByZWVtcHRpb24iLA0KICAgICAgICAgICAgICBkcmFmdC1iYWJpYXJ6LXBjbi1z aXAtY2FwLTAwICh3b3JrIGluIHByb2dyZXNzKSwNCiAgICAgICAgICAgICAgT2N0b2JlciAyMDA2 Lg0KDQogICBbSS1ELmlldGYtdHN2d2ctZWNuLW1wbHNdDQogICAgICAgICAgICAgIERhdmllLCBC LiwgIkV4cGxpY2l0IENvbmdlc3Rpb24gTWFya2luZyBpbiBNUExTIiwNCiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbXBscy0wMSAod29yayBpbiBwcm9ncmVzcyksDQogICAgICAg ICAgICAgIEp1bmUgMjAwNy4NCg0KICAgW0ktRC5sZWZhdWNoZXVyLXJzdnAtZWNuXQ0KICAgICAg ICAgICAgICBGYXVjaGV1ciwgRi4sICJSU1ZQIEV4dGVuc2lvbnMgZm9yIEFkbWlzc2lvbiBDb250 cm9sIG92ZXINCiAgICAgICAgICAgICAgRGlmZnNlcnYgdXNpbmcgUHJlLWNvbmdlc3Rpb24gIE5v dGlmaWNhdGlvbiAoUENOKSIsDQogICAgICAgICAgICAgIGRyYWZ0LWxlZmF1Y2hldXItcnN2cC1l Y24tMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLA0KICAgICAgICAgICAgICBKdW5lIDIwMDYuDQoNCiAg IFtJLUQuY2hhbi1wY24tcHJvYmxlbS1zdGF0ZW1lbnRdDQogICAgICAgICAgICAgIENoYW4sIEsu LCAiUHJlLUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFByb2JsZW0gU3RhdGVtZW50IiwNCiAgICAg ICAgICAgICAgZHJhZnQtY2hhbi1wY24tcHJvYmxlbS1zdGF0ZW1lbnQtMDEgKHdvcmsgaW4gcHJv Z3Jlc3MpLA0KICAgICAgICAgICAgICBPY3RvYmVyIDIwMDYuDQoNCiAgIFtJLUQuaWV0Zi1wd2Uz LWNvbmdlc3Rpb24tZnJtd2tdDQogICAgICAgICAgICAgIEJyeWFudCwgUy4sICJQc2V1ZG93aXJl IENvbmdlc3Rpb24gQ29udHJvbCBGcmFtZXdvcmsiLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRm LXB3ZTMtY29uZ2VzdGlvbi1mcm13ay0wMCAod29yayBpbiBwcm9ncmVzcyksDQogICAgICAgICAg ICAgIEZlYnJ1YXJ5IDIwMDcuDQoNCiAgIFtJLUQuYnJpc2NvZS10c3Z3Zy1lY24tdHVubmVsXQ0K ICAgICAgICAgICAgICAiIiwgPGh0dHA6Ly93d3cud2F0ZXJzcHJpbmdzLm9yZy9wdWIvaWQvDQog ICAgICAgICAgICAgIGJyaXNjb2UtdHN2d2ctZWNuLXR1bm5lbC0wMC50eHQ+Lg0KDQogICBbSS1E LmJyaXNjb2UtcmUtcGNuLWJvcmRlci1jaGVhdF0NCiAgICAgICAgICAgICAgIiIsIDxodHRwOi8v d3d3LndhdGVyc3ByaW5ncy5vcmcvcHViL2lkLw0KICAgICAgICAgICAgICBicmlzY29lLXJlLXBj bi1ib3JkZXItY2hlYXQtMDAudHh0Pi4NCg0KICAgW0ktRC5iZWhyaW5nZXItdHN2d2ctcnN2cC1z ZWN1cml0eS1ncm91cGtleWluZ10NCiAgICAgICAgICAgICAgIiIsIDxodHRwOi8vd3d3LndhdGVy c3ByaW5ncy5vcmcvcHViL2lkLw0KICAgICAgICAgICAgICBiZWhyaW5nZXItdHN2d2ctcnN2cC1z ZWN1cml0eS1ncm91cGtleWluZy0wMC50eHQ+Lg0KDQogICBbSS1ELmVhcmRsZXktcGNuLWFyY2hp dGVjdHVyZV0NCiAgICAgICAgICAgICAgIiIsIDxodHRwOi8vd3d3LndhdGVyc3ByaW5ncy5vcmcv cHViL2lkLw0KICAgICAgICAgICAgICBkcmFmdC1lYXJkbGV5LXBjbi1hcmNoaXRlY3R1cmUtMDAu dHh0Pi4NCg0KICAgW0ktRC5jaGFuLXBjbi1lbmNvZGluZy1jb21wYXJpc29uXQ0KICAgICAgICAg ICAgICAiIiwgPGh0dHA6Ly93d3cud2F0ZXJzcHJpbmdzLm9yZy9wdWIvaWQvDQogICAgICAgICAg ICAgIGRyYWZ0LWNoYW4tcGNuLWVuY29kaW5nLWNvbXBhcmlzb24tMDAudHh0Pi4NCg0KDQoNCg0K RWFyZGxleSAoRWRpdG9yKSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA5LCAyMDA4ICAgICAgICAg ICAgICAgW1BhZ2UgMjldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIERvY3Vt ZW50ICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDcNCg0KDQogICBbUkZDNDc3NF0gIEZs b3lkLCBTLiwgIlNwZWNpZnlpbmcgQWx0ZXJuYXRlIFNlbWFudGljcyBmb3IgdGhlDQogICAgICAg ICAgICAgIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIEZpZWxkIiwgQkNQ IDEyNCwNCiAgICAgICAgICAgICAgUkZDIDQ3NzQsIE5vdmVtYmVyIDIwMDYuDQoNCiAgIFtSRkMy NDc1XSAgQmxha2UsIFMuLCBCbGFjaywgRC4sIENhcmxzb24sIE0uLCBEYXZpZXMsIEUuLCBXYW5n LCBaLiwNCiAgICAgICAgICAgICAgYW5kIFcuIFdlaXNzLCAiQW4gQXJjaGl0ZWN0dXJlIGZvciBE aWZmZXJlbnRpYXRlZA0KICAgICAgICAgICAgICBTZXJ2aWNlcyIsIFJGQyAyNDc1LCBEZWNlbWJl ciAxOTk4Lg0KDQogICBbUkZDMzI0Nl0gIERhdmllLCBCLiwgQ2hhcm55LCBBLiwgQmVubmV0LCBK LiwgQmVuc29uLCBLLiwgTGUgQm91ZGVjLA0KICAgICAgICAgICAgICBKLiwgQ291cnRuZXksIFcu LCBEYXZhcmksIFMuLCBGaXJvaXUsIFYuLCBhbmQgRC4NCiAgICAgICAgICAgICAgU3RpbGlhZGlz LCAiQW4gRXhwZWRpdGVkIEZvcndhcmRpbmcgUEhCIChQZXItSG9wDQogICAgICAgICAgICAgIEJl aGF2aW9yKSIsIFJGQyAzMjQ2LCBNYXJjaCAyMDAyLg0KDQogICBbUkZDNDU5NF0gIEJhYmlhcnos IEouLCBDaGFuLCBLLiwgYW5kIEYuIEJha2VyLCAiQ29uZmlndXJhdGlvbg0KICAgICAgICAgICAg ICBHdWlkZWxpbmVzIGZvciBEaWZmU2VydiBTZXJ2aWNlIENsYXNzZXMiLCBSRkMgNDU5NCwNCiAg ICAgICAgICAgICAgQXVndXN0IDIwMDYuDQoNCiAgIFtSRkMzMTY4XSAgUmFtYWtyaXNobmFuLCBL LiwgRmxveWQsIFMuLCBhbmQgRC4gQmxhY2ssICJUaGUgQWRkaXRpb24NCiAgICAgICAgICAgICAg b2YgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gSVAiLA0KICAgICAg ICAgICAgICBSRkMgMzE2OCwgU2VwdGVtYmVyIDIwMDEuDQoNCiAgIFtSRkMyMjExXSAgV3JvY2xh d3NraSwgSi4sICJTcGVjaWZpY2F0aW9uIG9mIHRoZSBDb250cm9sbGVkLUxvYWQNCiAgICAgICAg ICAgICAgTmV0d29yayBFbGVtZW50IFNlcnZpY2UiLCBSRkMgMjIxMSwgU2VwdGVtYmVyIDE5OTcu DQoNCiAgIFtSRkMyOTk4XSAgQmVybmV0LCBZLiwgRm9yZCwgUC4sIFlhdmF0a2FyLCBSLiwgQmFr ZXIsIEYuLCBaaGFuZywgTC4sDQogICAgICAgICAgICAgIFNwZWVyLCBNLiwgQnJhZGVuLCBSLiwg RGF2aWUsIEIuLCBXcm9jbGF3c2tpLCBKLiwgYW5kIEUuDQogICAgICAgICAgICAgIEZlbHN0YWlu ZSwgIkEgRnJhbWV3b3JrIGZvciBJbnRlZ3JhdGVkIFNlcnZpY2VzIE9wZXJhdGlvbg0KICAgICAg ICAgICAgICBvdmVyIERpZmZzZXJ2IE5ldHdvcmtzIiwgUkZDIDI5OTgsIE5vdmVtYmVyIDIwMDAu DQoNCiAgIFtSRkMzMjcwXSAgTGUgRmF1Y2hldXIsIEYuLCBXdSwgTC4sIERhdmllLCBCLiwgRGF2 YXJpLCBTLiwgVmFhbmFuZW4sDQogICAgICAgICAgICAgIFAuLCBLcmlzaG5hbiwgUi4sIENoZXZh bCwgUC4sIGFuZCBKLiBIZWluYW5lbiwgIk11bHRpLQ0KICAgICAgICAgICAgICBQcm90b2NvbCBM YWJlbCBTd2l0Y2hpbmcgKE1QTFMpIFN1cHBvcnQgb2YgRGlmZmVyZW50aWF0ZWQNCiAgICAgICAg ICAgICAgU2VydmljZXMiLCBSRkMgMzI3MCwgTWF5IDIwMDIuDQoNCiAgIFtSRkMxNjMzXSAgQnJh ZGVuLCBCLiwgQ2xhcmssIEQuLCBhbmQgUy4gU2hlbmtlciwgIkludGVncmF0ZWQNCiAgICAgICAg ICAgICAgU2VydmljZXMgaW4gdGhlIEludGVybmV0IEFyY2hpdGVjdHVyZTogYW4gT3ZlcnZpZXci LA0KICAgICAgICAgICAgICBSRkMgMTYzMywgSnVuZSAxOTk0Lg0KDQogICBbUkZDMjk4M10gIEJs YWNrLCBELiwgIkRpZmZlcmVudGlhdGVkIFNlcnZpY2VzIGFuZCBUdW5uZWxzIiwNCiAgICAgICAg ICAgICAgUkZDIDI5ODMsIE9jdG9iZXIgMjAwMC4NCg0KICAgW1JGQzI3NDddICBCYWtlciwgRi4s IExpbmRlbGwsIEIuLCBhbmQgTS4gVGFsd2FyLCAiUlNWUCBDcnlwdG9ncmFwaGljDQogICAgICAg ICAgICAgIEF1dGhlbnRpY2F0aW9uIiwgUkZDIDI3NDcsIEphbnVhcnkgMjAwMC4NCg0KICAgW0lU VS1NTFBQXQ0KICAgICAgICAgICAgICAiTXVsdGlsZXZlbCBQcmVjZWRlbmNlIGFuZCBQcmUtZW1w dGlvbiBTZXJ2aWNlIChNTFBQKSIsDQogICAgICAgICAgICAgIElUVS1UIFJlY29tbWVuZGF0aW9u IEkuMjU1LjMsIDE5OTAuDQoNCg0KDQoNCkVhcmRsZXkgKEVkaXRvcikgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgOSwgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDMwXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBEb2N1bWVudCAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA3DQoNCg0KICAgW0l5ZXJdICAgICAiQW4gYXBwcm9hY2ggdG8gYWxsZXZpYXRlIGxpbmsgb3Zl cmxvYWQgYXMgb2JzZXJ2ZWQgb24gYW4NCiAgICAgICAgICAgICAgSVAgYmFja2JvbmUiLCBJRUVF IElORk9DT00gLCAyMDAzLA0KICAgICAgICAgICAgICA8aHR0cDovL3d3dy5pZWVlLWluZm9jb20u b3JnLzIwMDMvcGFwZXJzLzEwXzA0LnBkZj4uDQoNCiAgIFtTaGVua2VyXSAgIkZ1bmRhbWVudGFs IGRlc2lnbiBpc3N1ZXMgZm9yIHRoZSBmdXR1cmUgSW50ZXJuZXQiLCBJRUVFDQogICAgICAgICAg ICAgIEpvdXJuYWwgb24gc2VsZWN0ZWQgYXJlYXMgaW4gY29tbXVuaWNhdGlvbnMgcHAgMTE3NiAt DQogICAgICAgICAgICAgIDExODgsIFZvbCAxMyAoNyksIDE5OTUuDQoNCiAgIFtTb25naHVyc3Rd DQogICAgICAgICAgICAgICJHdWFyYW50ZWVkIFFvUyBTeW50aGVzaXMgZm9yIEFkbWlzc2lvbiBD b250cm9sIHdpdGgNCiAgICAgICAgICAgICAgU2hhcmVkIENhcGFjaXR5IiwgQlQgVGVjaG5pY2Fs IFJlcG9ydCBUUi1DWFI5LTIwMDYtMDAxLA0KICAgICAgICAgICAgICBGZWJ1cmFyeSAyMDA2LCA8 aHR0cDovL3d3dy5jcy51Y2wuYWMudWsvc3RhZmYvQi5CcmlzY29lLw0KICAgICAgICAgICAgICBw cm9qZWN0cy9pcGUyZXFvcy9ncXMvcGFwZXJzL0dRU19zaGFyZWRfdHIucGRmPi4NCg0KDQpBdXRo b3IncyBBZGRyZXNzDQoNCiAgIFBoaWxpcCBFYXJkbGV5DQogICBCVA0KICAgQjU0Lzc3LCBTaXJp dXMgSG91c2UgQWRhc3RyYWwgUGFyayBNYXJ0bGVzaGFtIEhlYXRoDQogICBJcHN3aWNoLCBTdWZm b2xrICBJUDUgM1JFDQogICBVbml0ZWQgS2luZ2RvbQ0KDQogICBFbWFpbDogcGhpbGlwLmVhcmRs ZXlAYnQuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpFYXJkbGV5IChFZGl0b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDksIDIwMDgg ICAgICAgICAgICAgICBbUGFnZSAzMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgRG9jdW1lbnQgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwNw0KDQoNCkZ1bGwgQ29w eXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3 KS4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2Vz IGFuZCByZXN0cmljdGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMg c2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0 cy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVU T1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JF RCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORA0K ICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJB TlRJRVMsIEVYUFJFU1MNCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQg VE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRg0KICAgVEhFIElORk9STUFUSU9OIEhFUkVJ TiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5U SUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RS4NCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9z aXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1l ZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNo bm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdo aWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3Qg YmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUg YW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZv cm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBS RkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAg IENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBh bmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBv ciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBs aWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkg cmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9u IGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQN CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBp bnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmln aHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5 DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJl ZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5m b3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkFja25v d2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHBy b3ZpZGVkIGJ5IHRoZSBJRVRGDQogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJ QVNBKS4NCg0KDQoNCg0KDQpFYXJkbGV5IChFZGl0b3IpICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDksIDIwMDggICAgICAgICAgICAgICBbUGFnZSAzMl0NCgwNCg== ------_=_NextPart_001_01C7DA08.7149792D 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://www1.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C7DA08.7149792D-- From pcn-bounces@ietf.org Wed Aug 08 18:08:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIthK-0000QL-CV; Wed, 08 Aug 2007 18:08:10 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIthI-0000QG-DO for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIthI-0000Q8-3k for pcn@ietf.org; Wed, 08 Aug 2007 18:08:08 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIthG-0003tu-Br for pcn@ietf.org; Wed, 08 Aug 2007 18:08:08 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 23:08:05 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Date: Wed, 8 Aug 2007 23:08:05 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A5@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Thread-Index: AcfOTJNiDbXXskhTRKOfZp0Z2OHPEQHbObcw From: To: , X-OriginalArrivalTime: 08 Aug 2007 22:08:05.0801 (UTC) FILETIME=[98978990:01C7DA08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Bob, Thanks for all the comments - tried to deal with them all. In-line summarises what I did with the more minor[?] ones.=20 Yes please on your offers of help: [1] writing the OAM section [2] supplying text about DoS for security considerations section ["The statement about DoS attacks is a requirement with no pointers to the detailed DOS issues, or any discussion of best practice design"] thanks! phil > -----Original Message----- > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R > Sent: 25 July 2007 00:44 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 > Phil and all the authors of this PCN architecture draft, >=20 > Like Lars, I'd like to congratulate you all on such a mature first draft, > and on managing to encompass many different views we have seen from > various > people without making the thing an uncontrollable monster full of options > and choices. >=20 > I just read it all through and my review comments are given below. >=20 > Also see > t-eardley-pcn-architecture-00_rvw_bb.pdf> > for suggested minor text changes. >=20 > I haven't supplied text for more major changes inline below until the > authors agree with the need for change. But then I can supply text if > required. >=20 > At 16:59 28/06/2007, philip.eardley@bt.com wrote: > >Hi all, > > > >Just a reminder that all comments on this draft would be great. It aims > >to describe the PCN architecture, in light of the PCN WG's Charter & its > >Milestone of an Info doc on 'Flow Admission and Termination Architecture > >within a Diffserv Domain' (due Nov 07). >=20 > General comments: >=20 > * WG process management > A lot of WG process management text, esp in S.3, but also the list of > possible flow termination mechanisms in S.4. All instances hilited in > magenta in the review at the above URL. > See separate mail about this to the PCN WG chairs (cc PCN list) > Subject: How to discuss WG scoping decisions in an RFC? There was no response, I think, on this point of your email. So I've been lazy and ignored this comment until consensus that something should be done! >=20 > * Choices vs decisions > I believe an architecture doc should say where one decision is required or > where multiple options are reasonable. Currently, the arch is good at > laying out the design space, but I'd like us to try to say which choices > have to be made by the IETF, which should be left to vendors and which > left > to operators. I think this is a fair point, however probably need to discuss specific examples on the list.=20 >=20 > >S1 Introduction. > >This is quite short. If desired, it could be boosted with a general > >explanation of where PCN fits into the picture of QoS and how it's > >evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01) I didn't move any of this text, or the Intro text in draft-chan-pcn-encoding-comparison-00 (my understanding is that the Intro text in the latter draft would basically vanish) >=20 > * Clarify that a packet might encounter more than one PCN domain along its > path, each being a separate admission control hop. This is mentioned in the Deployment scenario Section - which I move into the INtro. Hoping this solves it.=20 >=20 > * Clarify that a "Diffserv domain" may be multiple concatenated autonomous > systems, but in this draft they are assumed to trust each other and have > identical configuration. This is kind of covered in the Deployment scenario Section. If you think it isn't enough, please supply 'copy and paste' text (I don't feel confident that I'll get it exactly right with ref to RFC2475 definition of DS domain.) >=20 > >S2 Terminology > >In the "Editor's note" are 3 alternative terms that some of the authors > >preferred. >=20 > * ECN _and_ PCN marking? >=20 > " o Configured-termination-rate: [...] > Normally it is configured to be less than > the maximum rate at which PCN-traffic can be forwarded on the > link, so that termination-marking occurs before any significant > queuing, ECN-marking or loss of PCN-packets. > " >=20 > The above text implies (to me) that a PCN-interior router might do PCN > marking _and_ also ECN marking just before drop. That also imposes a > requirement on the encoding to be able to carry either in the same field. > I don't think the authors meant either of these implications.=20 Deleted such implications.=20 > So somewhere, > the relation between PCN & ECN marking should be stated. >=20 > Although this is perhaps too detailed for the architecture, I suggest that > any need for ECN marking on the same path but outside the PCN domain(s) > should be handled by tunnelling across the PCN domain, with a non-PCN DSCP > in the inner header (that turns on the RFC3168 meaning of its ECN field) > and a PCN DSCP in the outer. Separate mail thread on this.=20 >=20 > * Marking is when "current" rate is "above" a reference rate? >=20 > " o Admission-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > admissible-rate. >=20 > o Termination-marking: the marking of PCN-packets by a PCN-node to > indicate that the PCN-traffic on a link is above the configured- > termination-rate. > " >=20 > These marking definitions and other examples hilighted in magenta in the > above PDF prejudge marking mechanisms as rate measurements. >=20 > We don't just have marking when the _current_rate is _above_ the reference > rate. We can have marking when the _current_ rate is _below_, or when the > _past_ rate was _above_. >=20 > The configured rates are parameters of a (to be defined) mechanism. These > mechanisms will not have to mark packets when the rate is above these > configured rates. That depends on the mechanism. >=20 > This sounds picky, but it's actually a big rant I have about all this > loose > discussion of rate (yes, the issue of what rate means is mentioned in the > draft, but we need to be careful about such sloppy usage). IMHO, it's > important to scale our conception of time down to inter-arrival times, to > be precise. Then the rate is packet size/interarrival time. Therefore seen > at a small enough timescale, rate might be varying rapidly above and below > the configured rate. >=20 > A marking mechanism could be implemented by a virtual queue rather than a > rate measurement. When the offered instantaneous rate has been below the > configured-admission-rate for many packets (perhaps hundreds), marking > will > and should still occur,... if the virtual queue is still above a marking > threshold even if it is emptying rather than filling. This can be a > deliberate design choice that says we still want admission marking when > there has been recent overload to allow time for the control loop to work. > It ensures a greater safety margin is automatically created by the marking > mechanism when recent traffic had higher variance. This was the marking > algorithm that was most studied and simulated in CL-PHB draft. See separate email thread.=20 >=20 > The unintended implication that all packets are either marked or not > marked > should also be carefully avoided. The draft needs to say explicitly that > "Admission (or Termination) marking will be an encoding of some > combination > of codepoints in the IP header to signal a varying fractional number from > a > path of PCN-interior-nodes to a PCN-egress-node" I'm not sure this is accurate for either of the main categories of marking algorithm (threshold marking [=3Dstep marking of = cl-architecture], or excess-rate-marking [where a mark means so many bits in excess]). (it is true for ramp-marking of cl-architecture.) >=20 > * inelastic > Do you think we should define "inelastic" or is this a well-known IETF > term? We could refer to [Shenker95], which I think was the first to define > the term. Or is there an RFC that defines this (hopefully with ref to > Shenker)? >=20 > Scott Shenker, "Fundamental Design Issues for the Future Internet", In: > IEEE Journal on Selected Areas in Communications 13 (7) pp. 1176--1188 > (1995). Added >=20 >=20 > >S3 Assumptions and constraints on scope > >These are the 4 things mentioned in the Charter, plus some explanation > >of them. Are they clear? Also we mention some of the ways that a future > >revised Charter might look at overcoming some of the > >constraints/assumptions; is this sub-section at the right depth? >=20 > * Are all the scoping assumptions equal relaxable? >=20 > Just a thought: might it be worth giving an indication of which > assumptions > are likely to be hard or impossible to relax and which not (e.g. I think > the aggregation assumption is implicit to all MBAC (measurement-based Adm > Ctrl). Also inelasticity is fairly fundamental - you don't need admission > control if flows aren't inelastic. Whilst I personally agree, I'm not sure there's general agreement on which assumptions are the most relaxable. If other people would like text added on the lines bob suggests please shout (with specific suggestions), otherwise I'll leave as is. >=20 > This would affect the last para, which implies all the assumptions might > be > relaxed one day. >=20 > >S4 High-level functional architecture > >We have tried to write this section (and the following ones) so that it > >fits all the various proposals there've been for PCN mechanisms. Does > >this make the section too wishy-washy or too hard to understand? Should > >it include some comparison of the different mechanisms proposed > >(PCN-interior-node marking algorithms & PCN-boundary-node reactions)? >=20 > * Functional or topological? > Is it intentional that the high level functions are classified by which > type of node does them in 3 cases and what function is to be done in the > others? Would it be possible to define functions in the abstract first, > then say which functions have to be implemented on certain types of nodes? > Or does this just make it unnecessarily incomprehensible? [think your comment applies to S5, Detailed functional architecture] it was intentional. I found it the easiest way to describe it! >=20 > Gaps: > 1/ Discuss which PCN node needs to know the IP address of which other PCN > node in different configurations. And state requirements this implies on > the signalling protocol, or on configuration. > Minimally, only the egress needs to know the ingress address. In > centralised admission control scenarios, either the egress or the ingress > or both might need to be configured with a central address. I've added a new Section 5.7 on addressing, see separate thread.=20 >=20 > 2/ Related to knowing addresses of other nodes: When a PCN node receives a > message claiming to be from another PCN node, to validate the msg is > indeed > from the node it claims to be, are there any different issues that PCN > raises relative to typical reservation signalling systems? > draft-lefaucheur-rsvp-ecn-01 (expired) contains a good deal of text on > this > issue that should be generalised into this arch doc. Security consids section covers hopefully. I didn't find any text on security/authentication in that draft.=20 >=20 > >S5 Detailed Functional architecture > >Is this a reasonable description of the extra functionality that PCN > >requires on various nodes in the PCN-domain? Is it the right way to > >split up the description? For clarity / help reader's understanding, > >should there be some specific examples of how functionality might be > >distributed (eg "if you followed the deployment model in > >draft-briscoe-tsvwg-cl-architecture-04, then this measurement is made at > >the PCN-egress-node, communicated to the PCN-ingress-nodes which makes > >the admission decision; etc.") In S5.4 where I listed various possibilities for how the measurement /decision making functionality (for adm ctrl) is distributed (egress/ingress/centralised node), you made the comment (in your PDF comments) " Should we say how an implementation should know which option is being used? Negotiation? Configuration? The IETF standardise only one?" I've added "(we assume the operator would configure which is used)" Ok? >=20 > S.5.5 Probing functions >=20 > If we are going to consider a case where the ingress has prior knowledge > of > which egress is associated with which destination address (e.g. with a > separate signalling routing table as discussed in NSIS, or if the > signalling protocol goes receiver-sender-receiver), then the ingress could > know that it has no reservations with that egress as soon as a reservation > request arrives, so it can unilaterally start probling. Added. I actually re-wrote the probing section a bit. See separate thread.=20 >=20 > S.5.6 Flow Termination Functions >=20 > The text seems to assume the egress makes the decision on which flows to > lose and tells the ingress. In cl-architecture (for instance) the egress > meters, feeds back the measurement to the ingress, which meters the load > it > is forwarding and then the ingress calculates how much traffic to > terminate, and either chooses the flows itself, or asks a central node to > choose. >=20 > I think there has to be metering at both boundaries otherwise we can't > work > out how much traffic has been dropped (as well as termination marked). The > decision might be at either (but in cl-architecture we had good reasons > for > choosing the ingress because it has the most recent knowledge about load > (given flows might be being abandoned by users very quickly and/or added > very quickly during a disaster). >=20 > Other more incremental mechanisms have now been defined that don't > calculate how much load to shed in one pass, but keep trying. Have we > abandonned the earlier approach? >=20 > Whatever, I think a feedback function is missing between the boundary > nodes. Have clarified this section - re-wrote quite a bit.=20 >=20 > >S6 Design goals and challenges > >This briefly describes some open issues, taken from > >briscoe-tsvwg-cl-architecture. Are there other ones that should be > >mentioned? Is the problem description at the right level of depth? > >Should we discuss various possible solutions to these problems? >=20 > I get the feeling we need a doc specifically on ECMP solutions? I think there was some discussion on the list that a separate isn't needed at the moment. I wrote some revised text on ecmp - separate thread.=20 >=20 > >S7 Deployment scenarios > >Briefly describes some deployment scenarios for pcn? is this at the > >right level of depth? >=20 > Just a thought - I felt this section would have been better earlier. Moved to the end of the Intro. >=20 > >S8 Operations and Management > >This section was written in response to the Charter saying that the > >architecture document should include security, manageability and > >operational considerations. The draft addresses this by providing some > >thoughts under the FCAPS headings: OAM of Faults, Configuration, > >Accounting, Performance and Security? Is this the right way of > >structuring it - does it cover the right set of topics? Is the text at > >the right level? - eg should it also have a detailed set of parameters > >that would be available for configuration? >=20 > * Don't think this is Fault OAM? > Echoing what someone else (I forget who) said on the list, Fault OAM isn't > really about how the control system recovers from failures (that's > control), it's how to tell the management system/manual operator that you > have recovered from a failure (or not). >=20 > Also, we should cover faults other than node or link failures. E.g. a > wrongly configured address in a node, or a wrong address given in a > singalling protocol, or a wrongly configured parameter in a queueing algo. > Etc. >=20 > * Config OAM: Add: > - level of AM that leads to denying new admissions. > - config paramteres that control distribution of functions? >=20 > * Don't think this is Performance OAM? > I think Perf OAM is about monitoring performance at run-time, not > characterising performance at design time. >=20 > * Don't think this is Security OAM? > Again, as someone said, security OAM is finding out about security > breaches > or near-misses at run-time, not identifying security flaws in the design, > which is security the considerations section. Thanks for agreeing to (re)write the OAM section!! >=20 > * Security Considerations Gaps: I created the section by moving the old 'security oam' text, adding your points below plus others comments.=20 > - PCN marking selectively applied to certain flows, rather than randomly > by > interior node. > - The statement about DoS attacks is a requirement with no pointers to the > detailed DOS issues, or any discussion of best practice design. I could > supply text here (among many other things to do!) yes please! > - ref to hop-by-hop signalling authentication [RFC2747 for RSVP] and the > new recently posted draft to tsvwg on group keying for RSVP authentication > . I haven't read > it > yet, but on a scan it's as relevant as RFC2747. >=20 >=20 > Phew... that's all for now. >=20 >=20 > Bob >=20 >=20 > >An overall question is whether the draft should have more comparison of > >the options (pros/cons) for various aspects. > > > >I aim to edit another version of the draft before the ietf (but maybe > >not before the deadline as I'm on hols next week). > > > >Thanks! > >Phil/ >=20 > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 08 18:13:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItmF-0003j4-Pr; Wed, 08 Aug 2007 18:13:15 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IItmF-0003iz-Dl for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:13:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItmF-0003ir-2A for pcn@ietf.org; Wed, 08 Aug 2007 18:13:15 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IItmE-0003lG-6j for pcn@ietf.org; Wed, 08 Aug 2007 18:13:14 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 23:13:13 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Aug 2007 23:13:13 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A6@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN architecture - revised text on ECMP Thread-Index: AcfaCU+NgYL9vlL2RBe24G2bEVtecA== From: To: X-OriginalArrivalTime: 08 Aug 2007 22:13:13.0561 (UTC) FILETIME=[5007FC90:01C7DA09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Subject: [PCN] PCN architecture - revised text on ECMP X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1904476996==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1904476996== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DA09.4FC7798D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DA09.4FC7798D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to flag up that I wrote some revised text on ECMP (in Section 6, Design goals and challenges): =20 The following are open issues. They are taken from [I-D.briscoe-tsvwg-cl-architecture] which also describes some possible solutions (potential solutions are out of scope for this document). Note that some may be considered unimportant in general or in specific deployment scenarios. =20 =20 o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion is measured on a specific ingress-egress-aggregate. However, if the PCN-domain runs ECMP, then traffic on this ingress-egress- aggregate may follow several different paths - some of the paths could be pre-congested whilst others are not. There are two potential problems: =20 1. over-admission: a new flow is admitted (because the pre- congestion level measured by the PCN-egress-node is sufficiently diluted by unmarked packets from non-congested paths that a new flow is admitted), but its packets travel through a pre-congested PCN-node =20 2. ineffective termination: flows are terminated, however their path doesn't travel through the (pre-)congested router(s). =20 The overall PCN solution for flow termination must solve the second problem, since flow termination is a 'last resort'. For flow admission, the risk of slight over-admission may be acceptable (particularly with flow termination as a fall-back), at least for some operators. =20 =20 ------_=_NextPart_001_01C7DA09.4FC7798D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to flag up that I wrote some revised = text on ECMP (in Section 6, Design goals and challenges):

 

   The following are open issues.  They are taken = from

   [I-D.briscoe-tsvwg-cl-architecture] = which also describes some

   possible solutions (potential solutions are out of = scope for this

   document).  Note that some may be considered unimportant in general

   or in specific deployment = scenarios.

 

=  

   o  ECMP (Equal Cost Multi-Path) Routing: The = level of pre-congestion

      is measured on a specific ingress-egress-aggregate.  However, if

      the PCN-domain runs ECMP, then = traffic on this ingress-egress-

      aggregate may follow several = different paths - some of the paths

      could be pre-congested whilst = others are not.  There are two

      potential = problems:

 

      1.  over-admission: a new = flow is admitted (because the pre-

          = congestion level measured by the PCN-egress-node is

          = sufficiently diluted by unmarked packets from non-congested

          paths = that a new flow is admitted), but its packets travel

          through a pre-congested PCN-node

 

      2.  ineffective termination: = flows are terminated, however their

          path = doesn't travel through the (pre-)congested router(s).

 

      The overall PCN solution for flow termination must solve the

      second problem, since flow = termination is a 'last resort'.  For

      flow admission, the risk of = slight over-admission may be

      acceptable (particularly with = flow termination as a fall-back), at

      least for some = operators.

=  

 

=00 ------_=_NextPart_001_01C7DA09.4FC7798D-- --===============1904476996== 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://www1.ietf.org/mailman/listinfo/pcn --===============1904476996==-- From pcn-bounces@ietf.org Wed Aug 08 18:14:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItnD-0004X9-9k; Wed, 08 Aug 2007 18:14:15 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IItnB-0004X4-Nt for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:14:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItnB-0004Ww-BO for pcn@ietf.org; Wed, 08 Aug 2007 18:14:13 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IItnA-0003m1-Eo for pcn@ietf.org; Wed, 08 Aug 2007 18:14:13 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 23:14:06 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Aug 2007 23:14:11 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A7@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN architecture new section on tunnelling Thread-Index: AcfaCXJksAu35/rvTceRV0cJc3CgAw== From: To: X-OriginalArrivalTime: 08 Aug 2007 22:14:06.0437 (UTC) FILETIME=[6F8C3950:01C7DA09] X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Subject: [PCN] PCN architecture new section on tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735127217==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1735127217== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DA09.729CAC0D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DA09.729CAC0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about tunelling: =20 5.8. Tunnelling =20 It is possible that tunnels terminate at a PCN-node. It is important that any PCN-marking is preserved after decapsulation, so that it is still seen by the PCN-egress-node. To ensure this, on decapsulation the following rules are applied: =20 o the PCN-marking state of the inner and outer headers are compared =20 o if the inner header's marking state is more severe then it is preserved =20 o if the outer header's marking state is more severe then it is copied onto the inner header =20 o NB the order of increasing severity is: unmarked; PCN-marking with first encoding (ie associated with the PCN-lower-rate); PCN- marking with second encoding (ie associated with the PCN-upper- rate) =20 Similarly, if encapsulation is done within the PCN-domain, then the following rule is applied: =20 o any PCN-marking is copied into the outer header =20 Tunnelling considerations also depend on which header bits the PCN WG decides to use. If the ECN bits are used then [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to its spirit. If the DSCP field is used then [RFC2983] needs to be considered carefully. =20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes, in which case the rules above aren't needed. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow; even if ECMP is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path. But it also has drawbacks: additional overhead in terms of bandwidth and processing; and the effective elimination of ECMP as a load balancing mechanism. =20 =20 ------_=_NextPart_001_01C7DA09.729CAC0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to flag up that I wrote a new = sub-section (in Section 5, Detailed functional architecture) about = tunelling:

 

5.8.  Tunnelling

 

   It is possible that tunnels terminate at a = PCN-node.  It is important

   that any PCN-marking is preserved after = decapsulation, so that it is

   still seen by the PCN-egress-node.  To ensure = this, on decapsulation

   the following rules are applied:

 

   o  the PCN-marking state of the inner and = outer headers are compared

 

   o  if the inner header's marking state is more = severe then it is

      preserved

 

   o  if the outer header's marking state is more = severe then it is

      copied onto the inner = header

 

   o  NB the order of increasing severity is: = unmarked; PCN-marking with

      first encoding (ie associated = with the PCN-lower-rate); PCN-

      marking with second encoding (ie associated with the PCN-upper-

      rate)

 

   Similarly, if encapsulation is done within the = PCN-domain, then the

   following rule is applied:

 

   o  any PCN-marking is copied into the outer = header

 

   Tunnelling considerations also depend on which = header bits the PCN WG

   decides to use.  If the ECN bits are used = then

   [I-D.briscoe-tsvwg-ecn-tunnel] = applies; the rules above conform to

   its spirit.  If the DSCP field is used then = [RFC2983] needs to be

   considered carefully.

 

   An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to

   PCN-egress-nodes, in which case the rules above = aren't needed.  The

   potential reasons for doing such tunnelling are: = the PCN-egress-node

   then automatically knows the address of the = relevant PCN-ingress-node

   for a flow; even if ECMP is running, all = PCN-packets on a particular

   ingress-egress-aggregate follow the same = path.  But it also has

   drawbacks: additional overhead in terms of = bandwidth and processing;

   and the effective elimination of ECMP as a load = balancing mechanism.

 

 

=00 ------_=_NextPart_001_01C7DA09.729CAC0D-- --===============1735127217== 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://www1.ietf.org/mailman/listinfo/pcn --===============1735127217==-- From pcn-bounces@ietf.org Wed Aug 08 18:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItnr-0004ja-Ix; Wed, 08 Aug 2007 18:14:55 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IItnq-0004jQ-IL for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItnq-0004jI-8g for pcn@ietf.org; Wed, 08 Aug 2007 18:14:54 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IItno-0003yP-KD for pcn@ietf.org; Wed, 08 Aug 2007 18:14:54 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 23:14:51 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Aug 2007 23:14:51 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A8@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN architecture, new addressing sub-section Thread-Index: AcfaCYpY7OykUnWyQpmsyiTqOsc6qw== From: To: X-OriginalArrivalTime: 08 Aug 2007 22:14:51.0968 (UTC) FILETIME=[8AAFB400:01C7DA09] X-Spam-Score: -1.0 (-) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Subject: [PCN] PCN architecture, new addressing sub-section X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1770160712==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1770160712== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DA09.8A8EA62D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DA09.8A8EA62D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about addressing: =20 5.7. Addressing =20 PCN-nodes may need to know the address of other PCN-nodes: =20 o in all cases PCN-interior-nodes don't need to know the address of any other PCN-nodes, except their next hop neighbours =20 o in the cases of admission or termination decision by a PCN- boundary-node, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, at a minimum so that the PCN-ingress-node can be informed to enforce the admission decision through policing. The addressing information can be gathered from signalling, for example as described for RSVP in [I-D.lefaucheur-rsvp-ecn]. Alternatively, if PCN-traffic is always tunnelled across the PCN-domain, then the PCN-ingress- node's address is simply the source address of the outer packet header. =20 o in the cases of admission or termination decision by a central control node, the PCN-egress-node needs to be configured with the address of the centralised node. In addition, depending on the exact deployment scenario and its signalling, the centralised node may need to know the addresses of the PCN-ingress-node and PCN- egress-node, and the PCN-egress-node know the address of the PCN- ingress-node. NOTE: Consideration of the centralised case is out of scope of the initial PCN WG Charter. =20 =20 (I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder if the description of the centralised node case is too long, as the case is strictly out of scope.) =20 =20 ------_=_NextPart_001_01C7DA09.8A8EA62D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to flag up that I wrote a new = sub-section (in Section 5, Detailed functional architecture) about = addressing:

 

5.7.  Addressing

 

   PCN-nodes may need to know the address of other = PCN-nodes:

 

   o  in all cases PCN-interior-nodes don't need = to know the address of

      any other PCN-nodes, except their = next hop neighbours

 

   o  in the cases of admission or termination = decision by a PCN-

      boundary-node, the = PCN-egress-node needs to know the address of

      the PCN-ingress-node associated = with a flow, at a minimum so that

      the PCN-ingress-node can be = informed to enforce the admission

      decision through policing.  = The addressing information can be

      gathered from signalling, for = example as described for RSVP in

      [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic is

      always tunnelled across the = PCN-domain, then the PCN-ingress-

      node's address is simply the = source address of the outer packet

      header.

 

   o  in the cases of admission or termination = decision by a central

      control node, the PCN-egress-node = needs to be configured with the

      address of the centralised = node.  In addition, depending on the

      exact deployment scenario and its signalling, the centralised node

      may need to know the addresses of = the PCN-ingress-node and PCN-

      egress-node, and the = PCN-egress-node know the address of the PCN-

      ingress-node.  NOTE: = Consideration of the centralised case is out

      of scope of the initial PCN WG = Charter.

 

 

(I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about = different ways the egress could know the ingress address. Also, I wonder if the = description of the centralised node case is too long, as the case is strictly out of = scope.)

 

 

=00 ------_=_NextPart_001_01C7DA09.8A8EA62D-- --===============1770160712== 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://www1.ietf.org/mailman/listinfo/pcn --===============1770160712==-- From pcn-bounces@ietf.org Wed Aug 08 18:15:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItoS-0004m9-RQ; Wed, 08 Aug 2007 18:15:32 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IItoQ-0004m4-FC for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 18:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IItoQ-0004lw-5V for pcn@ietf.org; Wed, 08 Aug 2007 18:15:30 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IItoO-0003yx-B7 for pcn@ietf.org; Wed, 08 Aug 2007 18:15:30 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 23:15:27 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Aug 2007 23:15:27 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A9@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN architecture, revised sub-section on probing Thread-Index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgA== From: To: X-OriginalArrivalTime: 08 Aug 2007 22:15:27.0649 (UTC) FILETIME=[9FF43110:01C7DA09] X-Spam-Score: 0.0 (/) X-Scan-Signature: a38f40f81e96f7c17c0b6f9de20b7099 Subject: [PCN] PCN architecture, revised sub-section on probing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022623729==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2022623729== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DA09.9FBA1C8D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DA09.9FBA1C8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to flag up that I wrote a revised sub-section (in Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some other discussion we had on the list in july.=20 =20 5.5. Probing functions =20 Probing functions are optional, and can be used for admission control. A PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level. Probing is useful or even essential under the following conditions: =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision). It may be that the traffic levels on other ingress- egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. =20 o in the presence of multipath routing (ECMP) between the PCN- boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre- congested and hence can be admitted. =20 Probe packets may be simple data addressed to the PCN-egress-node and require no protocol standardisation, although there will be best practice for their number, size and rate. There are two possibilities for how probing is triggered: =20 o the PCN-egress-node requests (signals) the PCN-ingress-node to generate probe traffic =20 o if the PCN-ingress-node knows which PCN-egress-node is associated with the destination address in the admission request, then the PCN-ingress-node could know it has no reservation with that PCN- egress-node and unilaterally start probing. =20 The probing functions are: =20 o Make decision that probing is needed =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate- marking algorithm generates fewer PCN-marks than a threshold- marking algorithm. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 ------_=_NextPart_001_01C7DA09.9FBA1C8D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to flag up that I wrote a revised sub-section (in = Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some = other discussion we had on the list in july.

 

5.5.  Probing functions

 

   Probing functions are optional, and can be used for = admission

   control.  A PCN-ingress-node generates and = sends probe packets in

   order to test the pre-congestion level.  = Probing is useful or even

   essential under the following = conditions:

 

   o  when an ingress-egress-aggregate carries no traffic (or too little

      traffic for the PCN-egress-node = to accurately make the

      "measurements of = PCN-traffic" that are required for an admission

      decision).  It may be that = the traffic levels on other ingress-

      egress-aggregates are so high = that a new flow shouldn't be

      admitted on the 'empty' ingress-egress-aggregate.  Probing is

      useful to check = this.

 

   o  in the presence of multipath routing (ECMP) between the PCN-

      boundary-nodes, when some paths = are pre-congested there may be

      other paths which aren't pre-congested.  Probing is useful to

      determine whether the new flow = would follow a path that isn't pre-

      congested and hence can be = admitted.

 

   Probe packets may be simple data addressed to the = PCN-egress-node and

   require no protocol standardisation, although there = will be best

   practice for their number, size and rate.  = There are two

   possibilities for how probing is = triggered:

 

   o  the PCN-egress-node requests (signals) the PCN-ingress-node to

      generate probe = traffic

 

   o  if the PCN-ingress-node knows which PCN-egress-node is associated

      with the destination address in = the admission request, then the

      PCN-ingress-node could know it = has no reservation with that PCN-

      egress-node and unilaterally = start probing.

 

   The probing functions are:

 

   o  Make decision that probing is = needed

 

   o  (if required) Communicate the request that = probing is needed - the

      PCN-egress-node signals to the PCN-ingress-node that probe traffic

      is needed

 

   o  Generate probe traffic - the = PCN-ingress-node generates the probe

      traffic.  The appropriate = number (or rate) of probe packets will

      depend on the PCN-marking = algorithm; for example an excess-rate-

      marking algorithm generates fewer PCN-marks than a threshold-

      marking = algorithm.

 

   o  Forward probe packets - as far as PCN-interior-nodes are

      concerned, probe packets must be = handled the same as (ordinary

      data) = PCN-packets.

 

   o  Consume probe packets - the PCN-egress-node consumes probe packets

      to ensure that they don't travel = beyond the PCN-domain.

 

=00 ------_=_NextPart_001_01C7DA09.9FBA1C8D-- --===============2022623729== 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://www1.ietf.org/mailman/listinfo/pcn --===============2022623729==-- From pcn-bounces@ietf.org Wed Aug 08 21:08:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIwVz-0006Y0-Fm; Wed, 08 Aug 2007 21:08:39 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IIwVy-0006Xu-OA for pcn-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 21:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIwVy-0006Xm-D8 for pcn@ietf.org; Wed, 08 Aug 2007 21:08:38 -0400 Received: from smtp108.rog.mail.re2.yahoo.com ([68.142.225.206]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIwVw-0006NP-Qa for pcn@ietf.org; Wed, 08 Aug 2007 21:08:38 -0400 Received: (qmail 10609 invoked from network); 9 Aug 2007 01:08:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UvAKyO8n7z0AoD38LtNVLrh4G7/dzMe76LXpzsLsYqFbuHclql3U8tSTqzWpqu9vQ3hXLGityz2rbQp54yOFdpYcMkNiEEddomFqWJsEeka9oayq3qPgg6gmQ+vs0y1scQFoiXmpRpHaY7tPUw2J+qRTyYQk7LcyEJq04XEOQj8= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 9 Aug 2007 01:08:36 -0000 X-YMail-OSG: Yx.q6w4VM1lVxz6zgVUUR02PRxTo0kjAddUA4gzDA1xJYmdGpprltscYmRbL8YgEnA-- Message-ID: <46BA6948.8090409@rogers.com> Date: Wed, 08 Aug 2007 21:09:28 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] O+M section References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC39B@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC39B@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org My reason for including all those measurements was to make sure someone thought about them. I agree that this will not be the final list. As to your main point, I suppose I have to agree that a detailed list doesn't belong in an architecture document. However, the architecture document should talk about the applications of measurements and thereby lay down the requirements. I'll think about some alternate text. philip.eardley@bt.com wrote: > Tina, Tom, Bob, all, > > > > Thanks for this. > > > > A general comment - quite a lot of your changes to the section are to > add lists of parameters to be collected /configured etc at PCN-nodes. > Personally this seems a bit inappropriate to me for an architecture doc > - too detailed - better in a MIB?? (Incidentally I disagree with some > of the parameters.) > > > > I'll try and work in most of your other suggestions, whilst also reading > bob's input in parallel, which also says most of what I wrote is > rubbish. > > => the OAM section will shrink in this version as I'll delete most of > what I wrote. > > > > However, the good news is that Bob has offered to provide a whole new > OAM section (but not today, as he's currently enjoying the new improved > bt Expenses system!! - so it won't make this version). Maybe Tom and any > other keen OAMers can liaise with bob on this. > > > > Thanks! > > phil > > > > > > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: 25 July 2007 16:29 > To: pcn@ietf.org > Subject: [PCN] O+M section > > > > Hi all, > > As promised, attached please find the O+M section which was discussed in > the arch designing team. > > Hope it can be a basis or starting point as the O+M part in the ML. > > > > B. R. > Tina > Messengers: > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU > Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 09 07:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ5xo-00026f-CE; Thu, 09 Aug 2007 07:14:00 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJ5xm-0001te-9Z for pcn-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 07:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ5xl-0001sO-SG for pcn@ietf.org; Thu, 09 Aug 2007 07:13:57 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ5xk-0007W9-9L for pcn@ietf.org; Thu, 09 Aug 2007 07:13:57 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 734F9CB21; Thu, 9 Aug 2007 13:13:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 66175CB64; Thu, 9 Aug 2007 13:13:55 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 2A4A2CB21; Thu, 9 Aug 2007 13:13:54 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l79BDsh25685; Thu, 9 Aug 2007 13:13:54 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 78B176F591; Thu, 9 Aug 2007 13:07:49 +0200 (CEST) Message-ID: <46BAF62B.1050002@informatik.uni-wuerzburg.de> Date: Thu, 09 Aug 2007 13:10:35 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] PCN architecture, revised sub-section on probing References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A9@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A9@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: PCN IETF list X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, the text misses the fact that probing is more difficult in the presence of ECMP. In this case, probe packets must have the same header as future data packets to be routed on the same path in order to give answer whether precongestion is on that path or not. This is an essential aspect of probing and requires protocol standardization. Regards, Michael philip.eardley@bt.com wrote: > > This is to flag up that I wrote a revised sub-section (in Section 5, > Detailed functional architecture) about probing. to reflect > (hopefully!) some other discussion we had on the list in july. > > > > 5.5. Probing functions > > > > Probing functions are optional, and can be used for admission > > control. A PCN-ingress-node generates and sends probe packets in > > order to test the pre-congestion level. Probing is useful or even > > essential under the following conditions: > > > > o when an ingress-egress-aggregate carries no traffic (or too little > > traffic for the PCN-egress-node to accurately make the > > "measurements of PCN-traffic" that are required for an admission > > decision). It may be that the traffic levels on other ingress- > > egress-aggregates are so high that a new flow shouldn't be > > admitted on the 'empty' ingress-egress-aggregate. Probing is > > useful to check this. > > > > o in the presence of multipath routing (ECMP) between the PCN- > > boundary-nodes, when some paths are pre-congested there may be > > other paths which aren't pre-congested. Probing is useful to > > determine whether the new flow would follow a path that isn't pre- > > congested and hence can be admitted. > > > > Probe packets may be simple data addressed to the PCN-egress-node and > > require no protocol standardisation, although there will be best > > practice for their number, size and rate. There are two > > possibilities for how probing is triggered: > > > > o the PCN-egress-node requests (signals) the PCN-ingress-node to > > generate probe traffic > > > > o if the PCN-ingress-node knows which PCN-egress-node is associated > > with the destination address in the admission request, then the > > PCN-ingress-node could know it has no reservation with that PCN- > > egress-node and unilaterally start probing. > > > > The probing functions are: > > > > o Make decision that probing is needed > > > > o (if required) Communicate the request that probing is needed - the > > PCN-egress-node signals to the PCN-ingress-node that probe traffic > > is needed > > > > o Generate probe traffic - the PCN-ingress-node generates the probe > > traffic. The appropriate number (or rate) of probe packets will > > depend on the PCN-marking algorithm; for example an excess-rate- > > marking algorithm generates fewer PCN-marks than a threshold- > > marking algorithm. > > > > o Forward probe packets - as far as PCN-interior-nodes are > > concerned, probe packets must be handled the same as (ordinary > > data) PCN-packets. > > > > o Consume probe packets - the PCN-egress-node consumes probe packets > > to ensure that they don't travel beyond the PCN-domain. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 09 20:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHyE-0006RP-EU; Thu, 09 Aug 2007 20:03:14 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJHyC-0006R2-QP for pcn-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 20:03:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHyC-0006Q2-9u for pcn@ietf.org; Thu, 09 Aug 2007 20:03:12 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJHyB-0005Iz-M4 for pcn@ietf.org; Thu, 09 Aug 2007 20:03:12 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7A038317429; Fri, 10 Aug 2007 00:03:08 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG scoping decisions in an RFC?) Date: Thu, 9 Aug 2007 20:03:06 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511A3E1DC@zcarhxm1.corp.nortel.com> In-Reply-To: <46A747F8.30704@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG scoping decisions in an RFC?) Thread-Index: AcfOu4DmaEculjHdQOunh6pxQsKENQBy+4sA References: <1185312460.3454.53.camel@neutrino> <5.2.1.1.2.20070724214148.042b6568@pop3.jungle.bt.co.uk> <1185312460.3454.53.camel@neutrino> <5.2.1.1.2.20070725125353.04b36f20@pop3.jungle.bt.co.uk> <46A747F8.30704@informatik.uni-wuerzburg.de> From: "Jozef Babiarz" To: , "Bob Briscoe" X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: PCN IETF list X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Bob, Michael, In TSVWG about two years ago, it was decided that flow precedence information and control of it is to be handle in higher layers and not by the transport layer.=20 I believe that if we have precedence and normal traffic in the network that admission and flow termination of it is handled based on precedence information that is provided via signalling (SIP) during session setup or higher layers control protocol. The transport layer and the PCN mechanism is not precedence aware. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: July 25, 2007 8:54 AM To: Bob Briscoe Cc: PCN IETF list Subject: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG scoping decisions in an RFC?) Hi Bob, Bob Briscoe wrote: >>> Regarding emergency use: the charter says: >>> >>> (D) flows may have different precedence, but the applicability >>> of the PCN mechanisms for emergency use (911, GETS, WPS, >>> MLPP, etc.) is out of scope >>> >>> This could be interpreted in more than one way, but I interpret this as >>> saying that PCN-specific mechanisms will not take flow precedence into >>> account. Which is a different than saying that PCN cannot be used with >>> flow setup protocols/mechanisms that take flow precedence into account. >>> >> >> As soon as we have multiple PCN classes it might be useful to think=20 >> about flow precedence especially with regard to admission and=20 >> termination priority. Equal treatment of flows means that a highly=20 >> critical telemedicine application has the same probability to be=20 >> terminated as a "relatively" uncritcical VoIP call in case of a=20 >> disaster. I read the passage in the way that it's not our job to=20 >> define mechanisms for emergency use, but it is not prohibited to=20 >> extend PCN towards multiple classes with different requirements=20 >> although this is not the first thing to do. > > Michael, just to warn against your use of the word 'extend' PCN. > > For the avoidance of doubt, I think Steve's saying it is NOT in scope=20 > to extend PCN towards multiple classes with different requirements,=20 > but it is in scope for PCN to use (ie refer out to) other mechanisms=20 > that satisfy different emergency reqs, and similarly I guess it would=20 > be in scope to prove PCN doesn't stop these other mechanisms working. > > If I'm right, the txt in this arch draft is misleading and should be=20 > changed. The _applicability_ of PCN mechs for emergency use is in=20 > scope, but PCN-specific mechs for emergency use are out of scope. Sorry for using the word "extend", but I'm not sure whether I understand your answer correctly. We had the discussion about coexistence of=20 several PCN- and non-PCN classes already several times on the list and=20 it seemed to me that is an unsolved issue so far. When I say "extend=20 PCN" I mean adapting the currently discussed single-PCN-class mechanisms to work in a multi-class environment with a pre-defined number of PCN=20 classes. I do not talk about extending PCN for the need of specific=20 applications. The existence of multiple PCN classes has some impact on encoding and=20 possibly also on metering and marking, so this is a question that should be discussed before encoding is decided. As far as I can remember the=20 general view was that the charter does not forbid several PCN classes,=20 but it's not the first thing to be done. Are we in line or is your view=20 that there is and will be only a single PCN class that is coupled with a single PHB? Maybe this is an issue for discussion at the meeting, at=20 least to me, the answer of that question is not clear. Regards, Michael > > > Bob > > >> Regards, >> >> Michael >> >>> >>> Regards, >>> >>> = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D >>> Steven Blake >>> Ericsson/Redback Networks +1 919-472-9913 >>> >>> >>> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pcn >>> >> >> --=20 >> 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 > > ________________________________________________________________________ ____=20 > > Bob Briscoe, Networks Research Centre, BT=20 > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473=20 > 645196=20 --=20 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://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 10 11:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWVv-0004Wm-81; Fri, 10 Aug 2007 11:34:59 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJWVt-0004Wf-Uf for pcn-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 11:34:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWVt-0004WU-Ke for pcn@ietf.org; Fri, 10 Aug 2007 11:34:57 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJWVt-0006JE-AM for pcn@ietf.org; Fri, 10 Aug 2007 11:34:57 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l7AFcft3009562 for ; Fri, 10 Aug 2007 10:38:50 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 10:34:52 -0500 Received: from [147.117.169.108] ([147.117.169.108]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 10:34:52 -0500 From: Steven Blake To: pcn Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Fri, 10 Aug 2007 11:34:52 -0400 Message-Id: <1186760092.20697.46.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 15:34:52.0676 (UTC) FILETIME=[FED1DC40:01C7DB63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [PCN] PCN IETF69 Meeting Minutes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Without objection, I have uploaded the Chicago meeting minutes previously distributed. http://www3.ietf.org/proceedings/07jul/minutes/pcn.txt =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 10 13:27:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYHF-0003o4-QK; Fri, 10 Aug 2007 13:27:57 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJYHF-0003nH-1p for pcn-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYHE-0003n7-Nb for pcn@ietf.org; Fri, 10 Aug 2007 13:27:56 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYHD-0002xi-21 for pcn@ietf.org; Fri, 10 Aug 2007 13:27:56 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7AHRqt28044; Fri, 10 Aug 2007 17:27:52 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Fri, 10 Aug 2007 13:27:37 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511A3E79C@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A9@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAA2mD2g References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A9@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3595cdc4facf5cd9f085f547e103d0ed Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0582375843==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0582375843== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DB73.BF3FDBF7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DB73.BF3FDBF7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil and all, my comments below are denoted by [Joe].=20 =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, revised sub-section on probing =20 This is to flag up that I wrote a revised sub-section (in Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some other discussion we had on the list in july.=20 =20 5.5. Probing functions =20 Probing functions are optional, and can be used for admission control. A PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level. Probing is useful or even essential under the following conditions: =20 [Joe] We need to decide if probing is optional or a mandatory function. I think that we agree that it's needed if there is ECMP or some other form of multipath routing. We also need probing when there is no traffic present between ingress - egress for an aggregate or when there is only one flow per ingress -egress. Probing is also very useful to verify that media path is present between ingress and egress before new flow is admitted. This is useful to avid the condition of a person answering the phone and having no audio path available. When there are no tunnels between ingress-egress nodes, probing can be used to discover egress node and relay edge nodes address (more on this later). Finally, we are not sure if probing during admission of new flows would address issues of over admission or provide some mitigation against DoS attacks. We should have more information on this in few weeks. On the other hand, probing is not need if we know that there is no ECMP or multipath routing in the network and all ingress - egress aggregates will have at least one flow present before pre-congestion occurs. So maybe in this section we should word it such that it explains when probing is needed and what problems it solves. [end] =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision). It may be that the traffic levels on other ingress- egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. =20 [Joe] Agree that it's needed when there is no traffic between ingress-egress-aggregate. I also believe that probing should be very light weight, meaning that probing consume very little bandwidth in the network. [end] =20 o in the presence of multipath routing (ECMP) between the PCN- boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre- congested and hence can be admitted. =20 Probe packets may be simple data addressed to the PCN-egress-node and require no protocol standardisation, although there will be best practice for their number, size and rate. There are two possibilities for how probing is triggered: =20 [Joe] Probe packets need to have the same source/destination IP address, source/destination port number, protocol ID and DSCP value as media packets otherwise the network may route probe packets along a different path then media. [end] =20 o the PCN-egress-node requests (signals) the PCN-ingress-node to generate probe traffic =20 [Joe] I'm assuming this is to address the case when there is no traffic flowing in a pre setup ingress-egress aggregate? Comment, it will not be needed if we probe during admission of new flows. [end] =20 o if the PCN-ingress-node knows which PCN-egress-node is associated with the destination address in the admission request, then the PCN-ingress-node could know it has no reservation with that PCN- egress-node and unilaterally start probing. =20 [Joe] Do not understand how the PCN-ingress-node knows which PCN-egress-node the new flow that is going to be admitted will be routed through? Can you explain what you are thinking about here? [end] =20 The probing functions are: =20 o Make decision that probing is needed =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed =20 [Joe] I think the PCN-ingress-node needs to trigger probing. For admission control, it has a lot more information then the egress node. The PCN-ingress-node has or needs to have source/destination IP address, source/destination port numbers, protocol ID and DSCP value of the flow that is to be admitted. Using this information the PCN-ingress-node sends probe packets marked with IP header information as the new flow will once admitted to discover which PCN-egress-node the new flow will go through. The PCN-egress-node needs to intercept the probe packets and send back to probe originating PCN-ingress-node the pre-congestion information of the path between ingress-egress. For bi-directional flows this needs to be done in both directions before admission decision is made. [end] =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate- marking algorithm generates fewer PCN-marks than a threshold- marking algorithm. =20 [Joe] I do not think and from simulation I've seen to date that excess-rate-marking approach for admission control will work with probing. Excess-rate-marking requires a lot of packets to be received before any meaningful results can be obtained. [end] =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 [Joe] Yes, the PCN-egress-node needs to consume probe packets. [end] =20 [Joe] Final note on probing and admission control. I've been exchanging emails with Michael Menth on this subject and we are planning to write a short draft that goes into more details in this area. Planning to send it out to the list in September time frame. [end] =20 ------_=_NextPart_001_01C7DB73.BF3FDBF7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil and all, my comments below are denoted by [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, revised sub-section on probing

 

This is to flag up that I wrote a revised = sub-section (in Section 5, Detailed functional architecture) about probing. to = reflect (hopefully!) some other discussion we had on the list in july. =

 

5.5.  Probing = functions

 

   Probing functions are optional, = and can be used for admission

   control.  A = PCN-ingress-node generates and sends probe packets in

   order to test the pre-congestion level.  Probing is useful or even

   essential under the following = conditions:

 

[Joe] We need to = decide if probing is optional or a mandatory function. I think that we agree that it’s needed if there is ECMP or some other form of multipath = routing. We also need probing when there is no traffic present between ingress = – egress for an aggregate or when there is only one flow per ingress = –egress. Probing is also very useful to verify that media path is present between ingress and egress before new flow is admitted. This is useful to avid = the condition of a person answering the phone and having no audio path = available. When there are no tunnels between ingress-egress nodes, probing can be used = to discover egress node and relay edge nodes address (more on this later). =  Finally, we are not sure if probing during admission of new flows would address = issues of over admission or provide some mitigation against DoS attacks. We = should have more information on this in few weeks. On the other hand, =  probing is not need if we know that there is no ECMP or multipath routing in the = network and all ingress – egress aggregates will have at least one flow = present before pre-congestion occurs. So maybe in this section we should word it = such that it explains when probing is needed and what problems it solves. = [end]

 

   o  when an = ingress-egress-aggregate carries no traffic (or too little

      traffic for = the PCN-egress-node to accurately make the

      = "measurements of PCN-traffic" that are required for an = admission

      = decision).  It may be that the traffic levels on other = ingress-

      = egress-aggregates are so high that a new flow shouldn't be

      admitted on = the 'empty' ingress-egress-aggregate.  Probing is

      useful to = check this.

 

[Joe] Agree that = it’s needed when there is no traffic between ingress-egress-aggregate. I also believe that probing should be very light weight, meaning that probing = consume very little bandwidth in the network. [end]

 

   o  in the presence of = multipath routing (ECMP) between the PCN-

      = boundary-nodes, when some paths are pre-congested there may be

      other paths = which aren't pre-congested.  Probing is useful = to

      determine = whether the new flow would follow a path that isn't = pre-

      congested and = hence can be admitted.

 

   Probe packets may be simple data addressed to the PCN-egress-node and

   require no protocol = standardisation, although there will be best

   practice for their number, size = and rate.  There are two

   possibilities for how probing is triggered:

 

[Joe] Probe packets = need to have the same source/destination IP address, source/destination port number, = protocol ID and DSCP value as media packets otherwise the network may route probe packets along a different path then media. = [end]

 

   o  the PCN-egress-node = requests (signals) the PCN-ingress-node to

      generate probe = traffic

 

[Joe] I’m = assuming this is to address the case when there is no traffic flowing in a pre setup = ingress-egress aggregate? Comment, it will not be needed if we probe during admission = of new flows. [end]

 

   o  if the PCN-ingress-node = knows which PCN-egress-node is associated

      with the = destination address in the admission request, then the

      = PCN-ingress-node could know it has no reservation with that PCN-

      egress-node = and unilaterally start probing.

 

[Joe] Do not = understand how the PCN-ingress-node knows which PCN-egress-node the new flow that is going = to be admitted will be routed through? Can you explain what you are thinking = about here? [end]

 

   The probing functions = are:

 

   o  Make decision that = probing is needed

 

   o  (if required) = Communicate the request that probing is needed - the

      = PCN-egress-node signals to the PCN-ingress-node that probe traffic

      is = needed

 

[Joe] I think the PCN-ingress-node needs to trigger probing. For admission control, it has = a lot more information then the egress node. The PCN-ingress-node has or needs to = have source/destination IP address, source/destination port numbers, protocol = ID and DSCP value of the flow that is to be admitted. Using this information = the PCN-ingress-node sends probe packets marked with IP header information = as the new flow will once admitted to discover which PCN-egress-node the new = flow will go through. The PCN-egress-node needs to intercept the probe packets and = send back to probe originating PCN-ingress-node the pre-congestion = information of the path between ingress-egress. For bi-directional flows this needs to = be done in both directions before admission decision is made. = [end]

 

   o  Generate probe traffic - = the PCN-ingress-node generates the probe

      traffic.  = The appropriate number (or rate) of probe packets = will

      depend on the PCN-marking algorithm; for example an = excess-rate-

      marking = algorithm generates fewer PCN-marks than a threshold-

      marking = algorithm.

 

[Joe] I do not think = and from simulation I’ve seen to date that excess-rate-marking approach for admission control will work with probing. Excess-rate-marking requires a = lot of packets to be received before any meaningful results can be obtained. = [end]

 

   o  Forward probe packets - = as far as PCN-interior-nodes are

      concerned, = probe packets must be handled the same as = (ordinary

      data) = PCN-packets.

 

   o  Consume probe packets - = the PCN-egress-node consumes probe packets

      to ensure that = they don't travel beyond the PCN-domain.

 

[Joe] Yes, the = PCN-egress-node needs to consume probe packets. [end]

 

=

[Joe] Final note on = probing and admission control. I’ve been exchanging emails with Michael Menth = on this subject and we are planning to write a short draft that goes into more = details in this area. Planning to send it out to the list in September time = frame. [end]

 

------_=_NextPart_001_01C7DB73.BF3FDBF7-- --===============0582375843== 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://www1.ietf.org/mailman/listinfo/pcn --===============0582375843==-- From pcn-bounces@ietf.org Fri Aug 10 13:42:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYVk-000563-Q2; Fri, 10 Aug 2007 13:42:56 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJYVk-00055y-5m for pcn-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYVj-00055q-SZ for pcn@ietf.org; Fri, 10 Aug 2007 13:42:55 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYVi-0003Hr-H9 for pcn@ietf.org; Fri, 10 Aug 2007 13:42:55 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 18:42:53 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 18:42:42 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1186767760122; Fri, 10 Aug 2007 18:42:40 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.23]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7AHga4U015706; Fri, 10 Aug 2007 18:42:38 +0100 Message-Id: <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 10 Aug 2007 18:42:34 +0100 To: From: Bob Briscoe Subject: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A5@E03MVZ1-UKDY.doma in1.systemhost.net> References: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Aug 2007 17:42:42.0076 (UTC) FILETIME=[DA236DC0:01C7DB75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, At 23:08 08/08/2007, philip.eardley@bt.com wrote: > > The unintended implication that all packets are either marked or not > > marked > > should also be carefully avoided. The draft needs to say explicitly >that > > "Admission (or Termination) marking will be an encoding of some > > combination > > of codepoints in the IP header to signal a varying fractional number >from > > a > > path of PCN-interior-nodes to a PCN-egress-node" > >I'm not sure this is accurate for either of the main categories of >marking algorithm (threshold marking [=step marking of cl-architecture], >or excess-rate-marking [where a mark means so many bits in excess]). (it >is true for ramp-marking of cl-architecture.) 1/ threshold marking As load builds, assuming traffic isn't pure CBR, a queue will very likley be oscillating up and down quite fast. Here's a picture at packet granularity that I did about a year ago to illustrate this: Even if you have a step marking threshold at some queue length (any positive horizontal line across the top graph), only a proportion of packet will be marked. I believe Anna's simulations of step vs ramp demonstrated they weren't that different, which is what I would expect. A ramp merely ensures there is a smooth transition from zero marking to full marking even if the traffic doesn't provide any randomness itself (pure CBR) or its variable but highly smoothed by statistical aggregation. 2/ Excess rate marking Surely the whole point here is to mark a proportion of packets to signify the amount of excess rate. So I don't quite understand how it will either be 0% or 100% marking? Am I missing something? Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 10 13:44:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYXG-0006xJ-Cv; Fri, 10 Aug 2007 13:44:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJYXE-0006wY-Nb for pcn-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:44:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYXE-0006uE-4s for pcn@ietf.org; Fri, 10 Aug 2007 13:44:28 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYXB-0003Jl-Ku for pcn@ietf.org; Fri, 10 Aug 2007 13:44:27 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 18:44:24 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 18:14:28 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1186766067390; Fri, 10 Aug 2007 18:14:27 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.30]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7AHELdl014771; Fri, 10 Aug 2007 18:14:24 +0100 Message-Id: <5.2.1.1.2.20070810174236.0314abe0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 10 Aug 2007 18:14:21 +0100 To: "Jozef Babiarz" From: Bob Briscoe Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG scoping decisions in an RFC?) In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511A3E1DC@zcarhxm1.corp.nor tel.com> References: <46A747F8.30704@informatik.uni-wuerzburg.de> <1185312460.3454.53.camel@neutrino> <5.2.1.1.2.20070724214148.042b6568@pop3.jungle.bt.co.uk> <1185312460.3454.53.camel@neutrino> <5.2.1.1.2.20070725125353.04b36f20@pop3.jungle.bt.co.uk> <46A747F8.30704@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Aug 2007 17:14:28.0519 (UTC) FILETIME=[E8B32370:01C7DB71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: PCN IETF list X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, At 01:03 10/08/2007, Jozef Babiarz wrote: >Bob, Michael, >In TSVWG about two years ago, it was decided that flow precedence >information and control of it is to be handle in higher layers and not >by the transport layer. > >I believe that if we have precedence and normal traffic in the network >that admission and flow termination of it is handled based on precedence >information that is provided via signalling (SIP) during session setup >or higher layers control protocol. The transport layer and the PCN >mechanism is not precedence aware. What exactly do you mean by "the tsvwg decided"? I don't think the tsvwg (or the IETF) is in a position to decide how emergency services define the use of PHBs for emergencies. I would have thought this is an issue to be decided by governments and operators and there's no big standards implication whichever way they choose. Why would the IETF want or need to force a government's or operator's choice in this respect? The whole point of Diffserv is that the codepoints are there to be used as operators choose, with some standard ones. Certainly I believe the DoD don't like identifying precendence traffic in the data plane, as it might make it easier to target an attack at certain data. But the DoD is but a small part of the possible policy space in this area. In general, the IETF does vendor standards. If anyone was going to touch operational policy standards in the hot policy area of emergency services, I doubt very much it would be the IETF, which doesn't have the political/voting structures necessary for such a politically sensitive subject. Instead, I would imagine the IETF should produce protocols that cater for what seems a reasonable spectrum of likely policy choices. There does seem to be a valid technical motivation for specifying precedence both at the session/signalling layer and in the data plane. While a disaster or some emergency is in progress, routing and signalling will be continually being disrupted and trying to stabilise, leading to possibly continual excess traffic at various points in the data plane. Even if the emergency services have the right to signalling precedence over other flows, if the emergency is characterised by persistent or continuing disruption (earthquakes, riots, wars, DoS attacks etc), the emergency media may well still be unintelligible for extended periods while signalling is trying to deal with the storm. So in some operational regimes, data priority might be needed as well as signalling priority. To ensure precedence traffic floats on top of the persistently choppy waves of other traffic. Even if there was data plane precedence, PCN would not have to be precedence-aware. But when designing PCN we have to be aware of the possible combinatorial codepoint expansion. If we insisted that PCN is encoded in 3 DSCPs (say), then anyone that wanted to use n DSCPs for EF, would have to set aside 3 x n DSCPs for PCN. However, I admit, I know very little about operational practices or regulatory/military/emergency/government requirements around the world in this respect. I'm just saying it seems unlikely that every government in the world will have agreed on a signalling-only approach to precedence. Anyone have any facts? Bob >Regards, Joe >email:babiarz@nortel.com >Telephone:613-763-6098 >-----Original Message----- >From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >Sent: July 25, 2007 8:54 AM >To: Bob Briscoe >Cc: PCN IETF list >Subject: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG >scoping decisions in an RFC?) > >Hi Bob, > > >Bob Briscoe wrote: > >>> Regarding emergency use: the charter says: > >>> > >>> (D) flows may have different precedence, but the applicability > >>> of the PCN mechanisms for emergency use (911, GETS, WPS, > >>> MLPP, etc.) is out of scope > >>> > >>> This could be interpreted in more than one way, but I interpret this >as > >>> saying that PCN-specific mechanisms will not take flow precedence >into > >>> account. Which is a different than saying that PCN cannot be used >with > >>> flow setup protocols/mechanisms that take flow precedence into >account. > >>> > >> > >> As soon as we have multiple PCN classes it might be useful to think > >> about flow precedence especially with regard to admission and > >> termination priority. Equal treatment of flows means that a highly > >> critical telemedicine application has the same probability to be > >> terminated as a "relatively" uncritcical VoIP call in case of a > >> disaster. I read the passage in the way that it's not our job to > >> define mechanisms for emergency use, but it is not prohibited to > >> extend PCN towards multiple classes with different requirements > >> although this is not the first thing to do. > > > > Michael, just to warn against your use of the word 'extend' PCN. > > > > For the avoidance of doubt, I think Steve's saying it is NOT in scope > > to extend PCN towards multiple classes with different requirements, > > but it is in scope for PCN to use (ie refer out to) other mechanisms > > that satisfy different emergency reqs, and similarly I guess it would > > be in scope to prove PCN doesn't stop these other mechanisms working. > > > > If I'm right, the txt in this arch draft is misleading and should be > > changed. The _applicability_ of PCN mechs for emergency use is in > > scope, but PCN-specific mechs for emergency use are out of scope. > >Sorry for using the word "extend", but I'm not sure whether I understand > >your answer correctly. We had the discussion about coexistence of >several PCN- and non-PCN classes already several times on the list and >it seemed to me that is an unsolved issue so far. When I say "extend >PCN" I mean adapting the currently discussed single-PCN-class mechanisms > >to work in a multi-class environment with a pre-defined number of PCN >classes. I do not talk about extending PCN for the need of specific >applications. > >The existence of multiple PCN classes has some impact on encoding and >possibly also on metering and marking, so this is a question that should > >be discussed before encoding is decided. As far as I can remember the >general view was that the charter does not forbid several PCN classes, >but it's not the first thing to be done. Are we in line or is your view >that there is and will be only a single PCN class that is coupled with a > >single PHB? Maybe this is an issue for discussion at the meeting, at >least to me, the answer of that question is not clear. > >Regards, > >Michael > > > > > > > > Bob > > > > > >> Regards, > >> > >> Michael > >> > >>> > >>> Regards, > >>> > >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >>> Steven Blake > >>> Ericsson/Redback Networks +1 919-472-9913 > >>> > >>> > >>> > >>> _______________________________________________ > >>> PCN mailing list > >>> PCN@ietf.org > >>> https://www1.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 > > > > >________________________________________________________________________ >____ > > > > Bob Briscoe, Networks Research Centre, BT > > Research > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > > 645196 > >-- >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://www1.ietf.org/mailman/listinfo/pcn ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 10 14:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYpa-0003TN-Ih; Fri, 10 Aug 2007 14:03:26 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJYpZ-0003TH-Bo for pcn-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 14:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYpZ-0003T9-2I for pcn@ietf.org; Fri, 10 Aug 2007 14:03:25 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYpX-0003kr-Jn for pcn@ietf.org; Fri, 10 Aug 2007 14:03:25 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 19:03:22 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 19:03:20 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1186768999827; Fri, 10 Aug 2007 19:03:19 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.23]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7AI3GIl016390; Fri, 10 Aug 2007 19:03:19 +0100 Message-Id: <5.2.1.1.2.20070810185926.03f12d60@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 10 Aug 2007 19:03:14 +0100 To: From: Bob Briscoe Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt signal auth'n In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A5@E03MVZ1-UKDY.doma in1.systemhost.net> References: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Aug 2007 18:03:20.0841 (UTC) FILETIME=[BC7FF790:01C7DB78] X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, At 23:08 08/08/2007, philip.eardley@bt.com wrote: > > 2/ Related to knowing addresses of other nodes: When a PCN node >receives a > > message claiming to be from another PCN node, to validate the msg is > > indeed > > from the node it claims to be, are there any different issues that PCN > > raises relative to typical reservation signalling systems? > > draft-lefaucheur-rsvp-ecn-01 (expired) contains a good deal of text on > > this > > issue that should be generalised into this arch doc. > >Security consids section covers hopefully. I didn't find any text on >security/authentication in that draft. Some time after I said this, I went and looked myself and found it wasn't there. Sorry about this. When I've looked at what you've done, if I can add any insight, I'll try to supply text on this when I do the other security txt I promised. I had written some stuff on this in an early pre-I-D we never got round to publishing (I knew I'd seen it somewhere). Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 10 14:10:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYwf-0001f7-G1; Fri, 10 Aug 2007 14:10:45 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJYwe-0001bW-8Z for pcn-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 14:10:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYwd-0001aF-Rb for pcn@ietf.org; Fri, 10 Aug 2007 14:10:43 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJYwd-00029U-DT for pcn@ietf.org; Fri, 10 Aug 2007 14:10:43 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 19:07:52 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 18:58:03 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1186768682446; Fri, 10 Aug 2007 18:58:02 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.23]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7AHvvYZ016152; Fri, 10 Aug 2007 18:58:01 +0100 Message-Id: <5.2.1.1.2.20070810184610.03149b70@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 10 Aug 2007 18:57:46 +0100 To: From: Bob Briscoe Subject: RE: [PCN] draft-eardley-pcn-architecture-00 function v topology In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A5@E03MVZ1-UKDY.doma in1.systemhost.net> References: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Aug 2007 17:58:03.0512 (UTC) FILETIME=[FF5B6780:01C7DB77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, I should have said in the last mail that I'm picking off individual responses as new threads as I get time... At 23:08 08/08/2007, philip.eardley@bt.com wrote: > > * Functional or topological? > > Is it intentional that the high level functions are classified by >which > > type of node does them in 3 cases and what function is to be done in >the > > others? Would it be possible to define functions in the abstract >first, > > then say which functions have to be implemented on certain types of >nodes? > > Or does this just make it unnecessarily incomprehensible? > >[think your comment applies to S5, Detailed functional architecture] >it was intentional. I found it the easiest way to describe it! Yup sorry, I meant S5. Here's the contents: 5. Detailed Functional architecture . . . . . . . . . . . . . . . 12 5.1. PCN-interior-node functions . . . . . . . . . . . . . . . 12 5.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 13 5.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 13 5.4. Admission control functions . . . . . . . . . . . . . . . 14 5.5. Probing functions . . . . . . . . . . . . . . . . . . . . 14 5.6. Flow termination functions . . . . . . . . . . . . . . . . 15 It might just be worth saying it isn't actually just a purely functional architecture even tho the title says it is (or some such excuse). What's actually happening here is that the information and control necessary for a particular function naturally come together at a particular place in the directed topology of the domain. But many protocols are designed to carry information from the natural place of control to another place that wants to control the system. In the data plane, traffic flows in one direction, so the natural places are not easy to change. But in the signalling plane, you get all these wars over where control should be (sender, receiver, PDP, etc), which is what signalling protocols are meant to do - allow control to be moved around. In summary, these issues should be brought out explicitly in an arch doc, so something needs to be said about this rather than leaving it implicit. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 10 16:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJbTY-0007sL-9j; Fri, 10 Aug 2007 16:52:52 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJbTW-0007sC-DS for pcn-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 16:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJbTW-0007s3-3g for pcn@ietf.org; Fri, 10 Aug 2007 16:52:50 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJbTU-0007F6-FW for pcn@ietf.org; Fri, 10 Aug 2007 16:52:49 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7AKqjk21615; Fri, 10 Aug 2007 20:52:46 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, new addressing sub-section Date: Fri, 10 Aug 2007 16:52:04 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511A3EA6B@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A8@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, new addressing sub-section Thread-Index: AcfaCYpY7OykUnWyQpmsyiTqOsc6qwBaxDMw References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A8@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0630299813==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0630299813== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DB90.4F245B5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DB90.4F245B5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See my comments below demarked with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, new addressing sub-section =20 This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about addressing: =20 5.7. Addressing =20 PCN-nodes may need to know the address of other PCN-nodes: =20 o in all cases PCN-interior-nodes don't need to know the address of any other PCN-nodes, except their next hop neighbours =20 o in the cases of admission or termination decision by a PCN- boundary-node, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, at a minimum so that the PCN-ingress-node can be informed to enforce the admission decision through policing. The addressing information can be gathered from signalling, for example as described for RSVP in [I-D.lefaucheur-rsvp-ecn]. Alternatively, if PCN-traffic is always tunnelled across the PCN-domain, then the PCN-ingress- node's address is simply the source address of the outer packet header. [Joe] I believe that the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified "... enforce the admission and flow termination decision through policing." [end] =20 [Joe] Would also like to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. "Another method that may be used to discover and exchange address information between PCN-boundary-nodes is through probing. The PCN-ingerss-node using the IP header information of the flow to be admitted generates and sends probe packets that can easily be detected by the PCN-egress-node. The sent probe packets contain as payload the address of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow." [end] =20 o in the cases of admission or termination decision by a central control node, the PCN-egress-node needs to be configured with the address of the centralised node. In addition, depending on the exact deployment scenario and its signalling, the centralised node may need to know the addresses of the PCN-ingress-node and PCN- egress-node, and the PCN-egress-node know the address of the PCN- ingress-node. NOTE: Consideration of the centralised case is out of scope of the initial PCN WG Charter. =20 [Joe] I think we need a bit more discussion about the central control node. I'm thinking of something like a PDP where pre-congestion information is sent to and after verifying the policy the result is sent to PCN-ingress-node to care out the action. For this scenario, the PCN-boundary-nodes need to be provisioned with the address of the central policy control node. [end] =20 [Joe] Can the proponents of the central control node expand a bit more on how this will work? [end] =20 (I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder if the description of the centralised node case is too long, as the case is strictly out of scope.) =20 =20 ------_=_NextPart_001_01C7DB90.4F245B5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See my comments below demarked with = [Joe].

 

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

From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, new addressing sub-section

 

This is to flag up that I wrote = a new sub-section (in Section 5, Detailed functional architecture) about = addressing:

 

5.7.  = Addressing

 

   PCN-nodes may need to know the = address of other PCN-nodes:

 

   o  in all cases = PCN-interior-nodes don't need to know the address of

      any other = PCN-nodes, except their next hop neighbours

 

   o  in the cases of = admission or termination decision by a PCN-

      boundary-node, = the PCN-egress-node needs to know the address = of

      the = PCN-ingress-node associated with a flow, at a minimum so = that

      the = PCN-ingress-node can be informed to enforce the admission

      decision = through policing.  The addressing information can = be

      gathered from signalling, for example as described for RSVP = in

      [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic = is

      always = tunnelled across the PCN-domain, then the PCN-ingress-

      node's address = is simply the source address of the outer = packet

      = header.

[Joe] I believe that = the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified “... = enforce the admission and flow termination decision through policing.” = [end]

 

=

[Joe] Would also like = to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. “Another method that may be used to discover = and exchange address information between PCN-boundary-nodes is through = probing. The PCN-ingerss-node using the IP header information of the flow to be = admitted generates and sends probe packets that can easily be detected by the = PCN-egress-node. The sent probe packets contain as payload the address of the = PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion = information for that flow.” [end]

 

   o  in the cases of = admission or termination decision by a central

      control node, = the PCN-egress-node needs to be configured with = the

      address of the centralised node.  In addition, depending on = the

      exact = deployment scenario and its signalling, the centralised = node

      may need to = know the addresses of the PCN-ingress-node and PCN-

      egress-node, = and the PCN-egress-node know the address of the = PCN-

      = ingress-node.  NOTE: Consideration of the centralised case is = out

      of scope of = the initial PCN WG Charter.

 

[Joe] I think we need = a bit more discussion about the central control node. I’m thinking of = something like a PDP where pre-congestion information is sent to and after verifying = the policy the result is sent to PCN-ingress-node to care out the action. = For this scenario, the PCN-boundary-nodes need to be provisioned with the address of the = central policy control node. [end]

 

=

[Joe] Can the = proponents of the central control node expand a bit more on how this will work? = [end]

 

(I'm not completely happy with it. I'm not = sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder = if the description of the centralised node case is too long, as the case is = strictly out of scope.)

 

 

------_=_NextPart_001_01C7DB90.4F245B5A-- --===============0630299813== 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://www1.ietf.org/mailman/listinfo/pcn --===============0630299813==-- From pcn-bounces@ietf.org Sat Aug 11 03:04:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJl16-00019V-8h; Sat, 11 Aug 2007 03:04:08 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IJl12-00019O-OZ for pcn-confirm+ok@megatron.ietf.org; Sat, 11 Aug 2007 03:04:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJl0y-00019C-HN for pcn@ietf.org; Sat, 11 Aug 2007 03:04:01 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJl0x-0008IL-SS for pcn@ietf.org; Sat, 11 Aug 2007 03:04:00 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id BCBA5D31D; Sat, 11 Aug 2007 09:03:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A70B2D469; Sat, 11 Aug 2007 09:03:56 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 18ACBD31D; Sat, 11 Aug 2007 09:01:38 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l7B71ch07821; Sat, 11 Aug 2007 09:01:38 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 365456F591; Sat, 11 Aug 2007 08:55:31 +0200 (CEST) Message-ID: <46BD5E0D.6050803@informatik.uni-wuerzburg.de> Date: Sat, 11 Aug 2007 08:58:21 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking References: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Bob, Bob Briscoe wrote: > Phil, > > At 23:08 08/08/2007, philip.eardley@bt.com wrote: >> > The unintended implication that all packets are either marked or not >> > marked >> > should also be carefully avoided. The draft needs to say explicitly >> that >> > "Admission (or Termination) marking will be an encoding of some >> > combination >> > of codepoints in the IP header to signal a varying fractional number >> from >> > a >> > path of PCN-interior-nodes to a PCN-egress-node" >> >> I'm not sure this is accurate for either of the main categories of >> marking algorithm (threshold marking [=step marking of cl-architecture], >> or excess-rate-marking [where a mark means so many bits in excess]). (it >> is true for ramp-marking of cl-architecture.) > > 1/ threshold marking > > As load builds, assuming traffic isn't pure CBR, a queue will very > likley be oscillating up and down quite fast. Here's a picture at > packet granularity that I did about a year ago to illustrate this: > > > > Even if you have a step marking threshold at some queue length (any > positive horizontal line across the top graph), only a proportion of > packet will be marked. > > I believe Anna's simulations of step vs ramp demonstrated they weren't > that different, which is what I would expect. A ramp merely ensures > there is a smooth transition from zero marking to full marking even if > the traffic doesn't provide any randomness itself (pure CBR) or its > variable but highly smoothed by statistical aggregation. Threshold marking marks 0% of packets if the rate is significantly below the critical threshold and 100% of the packets if it is significantly above this threshold. Therefore, it also guearantees a fast transition from the 0% marked packets regime to the 100% marked packets regime when the rate increases. Certainly, there is a rate interval in between where only some packets are marked due to rate variability, but I hope that this does not create severe problems regarding under- or overadmission for large traffic aggregations. > > 2/ Excess rate marking > > Surely the whole point here is to mark a proportion of packets to > signify the amount of excess rate. So I don't quite understand how it > will either be 0% or 100% marking? Am I missing something? I guess this applies for threshold marking only. Excess rate marking leaves an amount of traffic with the token bucket rate unmarked. Michael > > > Bob > > > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 13 02:33:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKTUC-0004ip-Fj; Mon, 13 Aug 2007 02:33:08 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IKTUB-0004iZ-6Z for pcn-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 02:33:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKTUA-0004iO-OE for pcn@ietf.org; Mon, 13 Aug 2007 02:33:06 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKTU7-0001gw-D4 for pcn@ietf.org; Mon, 13 Aug 2007 02:33:06 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMP00CZJ8TZP3@szxga03-in.huawei.com> for pcn@ietf.org; Mon, 13 Aug 2007 14:32:23 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMP00F4K8TWY1@szxga03-in.huawei.com> for pcn@ietf.org; Mon, 13 Aug 2007 14:32:23 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMP00F1I8TV7Z@szxml03-in.huawei.com> for pcn@ietf.org; Mon, 13 Aug 2007 14:32:20 +0800 (CST) Date: Mon, 13 Aug 2007 14:32:19 +0800 From: Tina TSOU Subject: Re: [PCN] PCN architecture, new addressing sub-section To: pcn@ietf.org, philip.eardley@bt.com, Jozef Babiarz Message-id: <00c701c7dd73$b3409480$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A8@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB646511A3EA6B@zcarhxm1.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0743727338==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0743727338== Content-type: multipart/alternative; boundary="Boundary_(ID_D/KnPU0TXq/0tIjyed9YMw)" This is a multi-part message in MIME format. --Boundary_(ID_D/KnPU0TXq/0tIjyed9YMw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT ----- Original Message ----- From: Jozef Babiarz To: philip.eardley@bt.com ; pcn@ietf.org Sent: Saturday, August 11, 2007 4:52 AM Subject: RE: [PCN] PCN architecture, new addressing sub-section See my comments below demarked with [Joe]. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------------------------------------------------------------------------------ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, new addressing sub-section This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about addressing: 5.7. Addressing PCN-nodes may need to know the address of other PCN-nodes: o in all cases PCN-interior-nodes don't need to know the address of any other PCN-nodes, except their next hop neighbours o in the cases of admission or termination decision by a PCN- boundary-node, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, at a minimum so that the PCN-ingress-node can be informed to enforce the admission decision through policing. The addressing information can be gathered from signalling, for example as described for RSVP in [I-D.lefaucheur-rsvp-ecn]. Alternatively, if PCN-traffic is always tunnelled across the PCN-domain, then the PCN-ingress- node's address is simply the source address of the outer packet header. [Joe] I believe that the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified "... enforce the admission and flow termination decision through policing." [end] [Tina: sounds excellent.] [Joe] Would also like to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. "Another method that may be used to discover and exchange address information between PCN-boundary-nodes is through probing. The PCN-ingerss-node using the IP header information of the flow to be admitted generates and sends probe packets that can easily be detected by the PCN-egress-node. The sent probe packets contain as payload the address of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow." [end] [Tina: I found there is similarity between this probe method and RSVP method. The PCN ingress node places its address in the probe packet or RSVP PATH message, the interior nodes doesn't care about these packets, the PCN egress node could associate the flow with the correct PCN ingress node after extracting the address of the PCN ingress node embedded in the probe packet or RSVP PATH message. These kinds of methods have a disadvantage: it's hard for the egress node to merge the flows. A PCN egress node may create a mapping table like follows: FLOW FLOW's Ingress node flow1 Ingress A flow2 Ingress A flow3 Ingress B flow4 Ingress B If there are too many flows, the table may be very large. One option to solve addressing of PCN-boundary node may be to use symmetric route. For example, supposing IBGP is running on the PCN-boundary node: 1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress B----2.2.2.0/24 IBGP could tell the egress node B that it has to go through PCN ingress A to reach 1.1.1.0/24, the egress node B could then regard a packet from 1.1.1.0/24 will come through ingress A, given a symmetric route scenario. The disadvantage of this option may be the requirement of symmetric route. The advantage of this option is that merged table item may be supported. Network Network's Ingress node 1.1.1.0/24 Ingress A] o in the cases of admission or termination decision by a central control node, the PCN-egress-node needs to be configured with the address of the centralised node. In addition, depending on the exact deployment scenario and its signalling, the centralised node may need to know the addresses of the PCN-ingress-node and PCN- egress-node, and the PCN-egress-node know the address of the PCN- ingress-node. NOTE: Consideration of the centralised case is out of scope of the initial PCN WG Charter. [Joe] I think we need a bit more discussion about the central control node. I'm thinking of something like a PDP where pre-congestion information is sent to and after verifying the policy the result is sent to PCN-ingress-node to care out the action. For this scenario, the PCN-boundary-nodes need to be provisioned with the address of the central policy control node. [end] [Joe] Can the proponents of the central control node expand a bit more on how this will work? [end] [Tina: A centralized node will not burden the addressing of PCN-boundary nodes. To make metering, the egress node always has to know the ingress node address a flow associated. A centralized node makes the egress node doesn't need to notify the pre-congestion information (CLE) to the ingress node, instead, the egress node will send it to the centralized node. So the address of the centralized node has to be provisioned on the egress node. When the egress node notifies the CLE to the centralized node, it has to send the ingress node address associated the CLE. So the centralized would know the address of every PCN boundary node.] (I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder if the description of the centralised node case is too long, as the case is strictly out of scope.) ------------------------------------------------------------------------------ _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --Boundary_(ID_D/KnPU0TXq/0tIjyed9YMw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
 
----- Original Message -----
From:=20 Jozef = Babiarz=20
To: philip.eardley@bt.com ; pcn@ietf.org =
Sent: Saturday, August 11, 2007 = 4:52=20 AM
Subject: RE: [PCN] PCN = architecture, new=20 addressing sub-section

See my = comments below=20 demarked with [Joe].

 

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

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, new=20 addressing sub-section

 

This is to flag up that I wrote = a new=20 sub-section (in Section 5, Detailed functional architecture) about=20 addressing:

 

5.7.  = Addressing

 

   PCN-nodes may need to know the = address of=20 other PCN-nodes:

 

   o  in all cases = PCN-interior-nodes=20 don't need to know the address of

      any other = PCN-nodes,=20 except their next hop neighbours

 

   o  in the cases of = admission or=20 termination decision by a PCN-

      = boundary-node, the=20 PCN-egress-node needs to know the address = of

      the = PCN-ingress-node=20 associated with a flow, at a minimum so = that

      the = PCN-ingress-node=20 can be informed to enforce the admission

      decision = through=20 policing.  The addressing information can = be

      gathered from = signalling, for example as described for RSVP = in

     =20 [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic=20 is

      always = tunnelled across=20 the PCN-domain, then the PCN-ingress-

      node's = address is=20 simply the source address of the outer = packet

     =20 header.

[Joe] I believe = that the=20 PCN-ingress-node should enforce both the admission and flow = termination=20 decisions. So would suggest that the above text be modified =93... = enforce the=20 admission and flow termination decision through policing.=94=20 [end]

[Tina: sounds = excellent.] 

 

[Joe] Would also = like to add=20 that probing can be used to discover and exchange address information = of=20 PCN-boundary-nodes. =93Another method that may be used to discover and = exchange=20 address information between PCN-boundary-nodes is through probing. The = PCN-ingerss-node using the IP header information of the flow to be = admitted=20 generates and sends probe packets that can easily be detected by the=20 PCN-egress-node. The sent probe packets contain as payload the address = of the=20 PCN-ingress-node so that the PCN-egress-node knows where to send the=20 pre-congestion information for that flow.=94 = [end]

[Tina: I found=20 there is similarity between this probe method and RSVP method. The PCN = ingress=20 node places its address in the probe packet or RSVP PATH message, the = interior=20 nodes doesn't care about these packets, the PCN egress node could = associate=20 the flow with the correct PCN ingress node after extracting the = address of the=20 PCN ingress node embedded in the probe packet or RSVP PATH = message.
These=20 kinds of methods have a disadvantage: it's hard for the egress node to = merge=20 the flows. A PCN egress node may create a mapping table like=20 follows:
FLOW    FLOW's Ingress=20 node
flow1    Ingress=20 A
flow2    Ingress=20 A
flow3    Ingress=20 B
flow4    Ingress B
If there are too many = flows,=20 the table may be very large.
One option to solve addressing of = PCN-boundary=20 node may be to use symmetric route. For example, supposing IBGP is = running on=20 the PCN-boundary node:
1.1.1.0/24----PCN Ingress A---PCN interior=20 node-----PCN Egress B----2.2.2.0/24
IBGP could tell the egress node = B that=20 it has to go through PCN ingress A to reach 1.1.1.0/24, the egress = node B=20 could then regard a packet from 1.1.1.0/24 will come through ingress = A, given=20 a symmetric route scenario.
The disadvantage of this option may be = the=20 requirement of symmetric route. The advantage of this option is that = merged=20 table item may be supported.
Network   Network's = Ingress=20 node
1.1.1.0/24   Ingress=20 A] 

 

   o  in the cases of = admission or=20 termination decision by a central

      control node, = the=20 PCN-egress-node needs to be configured with = the

      address of = the=20 centralised node.  In addition, depending on=20 the

      exact = deployment=20 scenario and its signalling, the centralised = node

      may need to = know the=20 addresses of the PCN-ingress-node and = PCN-

      egress-node, = and the=20 PCN-egress-node know the address of the = PCN-

      = ingress-node. =20 NOTE: Consideration of the centralised case is=20 out

      of scope of = the initial=20 PCN WG Charter.

 

[Joe] I think we = need a bit=20 more discussion about the central control node. I=92m thinking of = something like=20 a PDP where pre-congestion information is sent to and after verifying = the=20 policy the result is sent to PCN-ingress-node to care out the action. = For this=20 scenario, the PCN-boundary-nodes need to be provisioned with the = address of=20 the central policy control node. [end]

 

[Joe] Can the = proponents=20 of the central control node expand a bit more on how this will = work?=20 [end]

[Tina: A centralized node will not burden the addressing of=20 PCN-boundary nodes. To make metering, the egress node always has to = know the=20 ingress node address a flow associated. A centralized node makes the = egress=20 node doesn=92t need to notify the pre-congestion information (CLE) to = the=20 ingress node, instead, the egress node will send it to the centralized = node.=20 So the address of the centralized node has to be provisioned on the = egress=20 node. When the egress node notifies the CLE to the centralized node, = it has to=20 send the ingress node address associated the CLE. So the centralized = would=20 know the address of every PCN boundary = node.]

 

(I'm not completely happy with it. I'm not = sure it=20 captures sufficiently the discussion there was a month or two back = about=20 different ways the egress could know the ingress address. Also, I = wonder if=20 the description of the centralised node case is too long, as the case = is=20 strictly out of scope.)

 

 

_______________________________________________
PCN mailing=20 = list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn
--Boundary_(ID_D/KnPU0TXq/0tIjyed9YMw)-- --===============0743727338== 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://www1.ietf.org/mailman/listinfo/pcn --===============0743727338==-- From pcn-bounces@ietf.org Tue Aug 14 11:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyN1-000135-MB; Tue, 14 Aug 2007 11:31:47 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IKyN0-00012w-DA for pcn-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 11:31:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyN0-00012o-2O for pcn@ietf.org; Tue, 14 Aug 2007 11:31:46 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKyMz-0007vY-1k for pcn@ietf.org; Tue, 14 Aug 2007 11:31:45 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:31:43 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Consensus call: movingdraft-chan-pcn-encoding-comparison-00 to working group document Date: Tue, 14 Aug 2007 16:31:43 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3D6@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <2CCC0BFE-6DDF-4027-836E-0816484667DB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus call: movingdraft-chan-pcn-encoding-comparison-00 to working group document Thread-Index: AcfQcFdGcbMX2OslQh2MACnNbWGt+AOCKVZQ From: To: X-OriginalArrivalTime: 14 Aug 2007 15:31:43.0998 (UTC) FILETIME=[3802E1E0:01C7DE88] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I thought about this more (101 uses for boring meetings). For the I-D I suggest: Part A: lists the encodings Part B: discusses pros and cons of them Part A, I entirely agree with the approach that Bruce suggests below, ie draft just says various approaches require 2, 3 (& 4?) codepoints (PCN-marked, unmarked; etc), and for each then list encoding options (DSCP-1, DSCP-2 OR ECN-'11', ECN-'00'; etc). I'd stick here to simply how many codepoints the PCN mechanism itself requires; there are some specific encodings that actually under a given set of scenario assumptions need more codepoints, but I'd deal with that under Part B as a disadvantage. Part B I think this nicely divides into 'issues for encodings that use dscp field' and 'issues for encodings that use ecn field'. Encodings that use both get both sets of issues [if it's more complicated than that, consider later in detail, basically a second order issue] For encodings that uses DSCP field: 1. interactions with multiple PCN classes. Ie if there are n PCN classes, you need n times as many codepoints (=3Ddscps). Because = PCN-nodes use DSCPs to distinguish PCN classes. This is a particular issue for operating PCN in an MPLS network, where you have less codepoint space (same argument probably applies to PCN on other networks eg Ethernet?). one option is simply to insist that there's only 1 pcn class (nb not what the architecture draft says). 2. interactions with ECMP. ECMP algos can use a packet's DSCP when deciding what interface to fwd it on. In a PCN-domain running ECMP, for a flow which has some packets PCN-marked and some unmarked. its packets will travel over more than one path. This may well lead to mis-ordering. ug. Maybe some more complicated interactions, esp if there are multiple pre-congested nodes... not sure. 3. maybe something about dscps being quite lightly standardised - limited rules on how you use them, largely up to the operator.=20 4. interactions with RFC4794 use of ecn field. None.=20 For encodings that use ECN field: 1. interactions with ECMP. None. ECMP algos don't use a packet's ECN field when deciding what interface to fwd it on 2. interactions with multiple PCN classes. None. Doesn't change the number of codepoints needed.=20 in the bullets below, '(un)planned' isn't quite the right word. I'm trying to distinguish between cases where everything is behaving correctly and cases where something is misconfigured or something else has gone wrong.=20 3. 'planned' interactions with CE (ie a pkt arrives, in a PCN class, at PCN-ingress-node with CE). The architecture draft (S3.5) has some text on how this is handled (basically, the default option is just to drop the pkt). 4. 'planned' interactions with ECT (ie a pkt arrives at PCN-ingress-node with ECT-1 or ECT-0). Probably best to forward the pkt (effectively re-set to '00'), or else drop as per CE pkts? 5. 'unplanned' interactions with ECN. These are some of the things said or suggested in [RFC4774], I think the 3 main categories are: - a RFC4774 pkt gets accidentally dscp-re-marked to the pcn-dscp; a PCN-ingress-node gets misconfigured so it allows a RFC4774 pkt in on the pcn-dscp. Can anything nasty happen? - a router in the PCN-domain misconfigures itself so it's RFC3246-enabled (ie no longer PCN-enabled). Can anything nasty happen, eg when PCN-marked pkts encounter this router? - a PCN-egress-node gets misconfigured so it allows a pcn-marked pkt 'out' of the PCN-domain.=20 this section is a bit trickier to think about; it needs a short para on each possible misconfiguration scenario to explain what the (potential) issue is; they're definitely not equally important. Also, we should make sure the discussion is confined to ecn-pcn interactions (I have a feeling it would be easy to get side-tracked into wider misconfiguration issues that have nothing to do with encoding choice) there are a few very detailed issues (eg in S11.6.4 & 11.6.5 of draft-briscoe-tsvwg-cl-phb-03, but we can ignore for now I think) anyway, I think the whole thing could be done in a nice short draft (5 pages of real text?) best wishes,=20 phil/ > -----Original Message----- > From: Bruce Davie [mailto:bdavie@cisco.com] > Sent: 27 July 2007 18:05 > To: Steven Blake > Cc: pcn > Subject: Re: [PCN] Consensus call: movingdraft-chan-pcn-encoding- > comparison-00 to working group document >=20 > I think the draft needs so much revision at this point that I would > rather wait for the next version before deciding if it is ready to be > a WG document. >=20 > Specifically, the draft needs to avoid replicating so much material > from other sources. Almost everything in sections 1 and 2 should be > removed. The place to define or discuss PCN motivation, terminology, > architecture, etc., is in other drafts (such as the architecture > draft). This draft should only reference other drafts. If the authors > think they need some new terminology, I would urge them to get the > architecture team to include it in their draft. >=20 > This draft should consist of statements like "The approach to PCN > described in [Reference] requires N distinct packet markings > (codepoints). These codepoints could be encoded in the following ways: > - encoding A > - encoding B >=20 > etc. >=20 > And then discuss the tradeoffs among the different encoding approaches. >=20 > The authors should be careful to distinguish between the state of a > *node* and a marking of a *packet* (e.g. a node might be in a > severely congested state, in which case it wants to be terminating > some flows, leading to some marking of packets with a "terminate" > marking. But note that a node will often generate several different > markings while in a given state, hence states and markings are not > equivalent.) I think the attempt to make this distinction was what > led to the notion of "features" which most people (including me) > seemed to find confusing. >=20 > This looks like a pretty major rewrite to me. >=20 > Bruce >=20 > On Jul 27, 2007, at 10:25 AM, Steven Blake wrote: >=20 > > PCN, > > > > During the Chicago PCN meeting, the authors of > > draft-chan-pcn-encoding-comparison-00 asked that this draft become a > > working group document. Based on the discussion in the room, the PCN > > chairs determined that there was no consensus amongst the meeting > > participants to move this version of the draft to a working group > > document at this time. There was a comment made that if certain > > simplifications were made in the next version of the draft (e.g., > > reducing the amount of text on marking semantics and concentrating on > > syntax), then the draft then would be ready to move to working group > > document. The chairs asked the authors to consider this approach. > > More > > details of the discussion will be available when the meeting > > minutes are > > posted. > > > > This email is a request for comments on moving > > draft-chan-pcn-encoding-comparison-00 to working group document. > > Please > > send your comments to the list within the next week. > > > > > > Scott & Steve > > > > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 14 14:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0wY-0003oN-NR; Tue, 14 Aug 2007 14:16:38 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IL0wY-0003oH-26 for pcn-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 14:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0wX-0003o9-OD for pcn@ietf.org; Tue, 14 Aug 2007 14:16:37 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL0wW-0002Gu-9m for pcn@ietf.org; Tue, 14 Aug 2007 14:16:37 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7EIGXD16919; Tue, 14 Aug 2007 18:16:34 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture new section on tunnelling Date: Tue, 14 Aug 2007 14:16:33 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511B2415D@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A7@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture new section on tunnelling Thread-Index: AcfaCXJksAu35/rvTceRV0cJc3CgAwEkoZpg References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A7@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427131981==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1427131981== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DE9F.3E5DFA3E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DE9F.3E5DFA3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, please see my comment below demarked with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:14 PM To: pcn@ietf.org Subject: [PCN] PCN architecture new section on tunnelling =20 This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about tunelling: =20 5.8. Tunnelling =20 It is possible that tunnels terminate at a PCN-node. It is important that any PCN-marking is preserved after decapsulation, so that it is still seen by the PCN-egress-node. To ensure this, on decapsulation the following rules are applied: =20 o the PCN-marking state of the inner and outer headers are compared =20 o if the inner header's marking state is more severe then it is preserved =20 o if the outer header's marking state is more severe then it is copied onto the inner header =20 o NB the order of increasing severity is: unmarked; PCN-marking with first encoding (ie associated with the PCN-lower-rate); PCN- marking with second encoding (ie associated with the PCN-upper- rate) =20 Similarly, if encapsulation is done within the PCN-domain, then the following rule is applied: =20 * any PCN-marking is copied into the outer header [Joe] The above may introduce unnecessary information leakage. Why not just at the encapsulation point mark all packets as unmarked. The decapsulation point can sort them out. Just realizes that excess rate marking approach will not work unless PCN-marking information is copied from inner to outer headers when encapsulating. [end] =20 [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN nonce) is out of scope as we are not sure if it's need for PCN. If not than the "PCN nonce" would also need to be copied to outer header. [end] =20 Tunnelling considerations also depend on which header bits the PCN WG decides to use. If the ECN bits are used then [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to its spirit. If the DSCP field is used then [RFC2983] needs to be considered carefully. =20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes, in which case the rules above aren't needed. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow; even if ECMP is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path. But it also has drawbacks: additional overhead in terms of bandwidth and processing; and the effective elimination of ECMP as a load balancing mechanism. =20 =20 ------_=_NextPart_001_01C7DE9F.3E5DFA3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil, please see my comment below = demarked with [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:14 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture new section on tunnelling

 

This is to flag up that I wrote = a new sub-section (in Section 5, Detailed functional architecture) about = tunelling:

 

5.8.  = Tunnelling

 

   It is possible that tunnels = terminate at a PCN-node.  It is important

   that any PCN-marking is = preserved after decapsulation, so that it is

   still seen by the = PCN-egress-node.  To ensure this, on decapsulation

   the following rules are = applied:

 

   o  the PCN-marking state of = the inner and outer headers are compared

 

   o  if the inner header's = marking state is more severe then it is

      = preserved

 

   o  if the outer header's = marking state is more severe then it is

      copied onto = the inner header

 

   o  NB the order of = increasing severity is: unmarked; PCN-marking with

      first encoding = (ie associated with the PCN-lower-rate); PCN-

      marking with = second encoding (ie associated with the PCN-upper-

      = rate)

 

   Similarly, if encapsulation is = done within the PCN-domain, then the

   following rule is = applied:

 

·         any = PCN-marking is copied into the outer header

[Joe] The above may = introduce unnecessary information leakage. Why not just at the encapsulation point mark all = packets as unmarked. The decapsulation point can sort them out. Just realizes = that excess rate marking approach will not work unless PCN-marking = information is copied from inner to outer headers when encapsulating. = [end]

 

=

[Joe] I’m = assuming for time being that “PCN nonce” (similar to ECN nonce) is out of = scope as we are not sure if it’s need for PCN. If not than the = “PCN nonce” would also need to be copied to outer header. [end] =

 

=

   Tunnelling considerations also = depend on which header bits the PCN WG

   decides to use.  If the ECN = bits are used then

   [I-D.briscoe-tsvwg-ecn-tunnel] = applies; the rules above conform to

   its spirit.  If the DSCP = field is used then [RFC2983] needs to be

   considered = carefully.

 

   An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to

   PCN-egress-nodes, in which case = the rules above aren't needed.  The

   potential reasons for doing such tunnelling are: the PCN-egress-node

   then automatically knows the = address of the relevant PCN-ingress-node

   for a flow; even if ECMP is = running, all PCN-packets on a particular

   ingress-egress-aggregate follow = the same path.  But it also has

   drawbacks: additional overhead = in terms of bandwidth and processing;

   and the effective elimination of = ECMP as a load balancing mechanism.

 

 

------_=_NextPart_001_01C7DE9F.3E5DFA3E-- --===============1427131981== 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://www1.ietf.org/mailman/listinfo/pcn --===============1427131981==-- From pcn-bounces@ietf.org Tue Aug 14 16:57:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3SV-0007ji-2Y; Tue, 14 Aug 2007 16:57:47 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IL3ST-0007jb-SC for pcn-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 16:57:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3ST-0007jT-EH for pcn@ietf.org; Tue, 14 Aug 2007 16:57:45 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL3ST-0001OM-1h for pcn@ietf.org; Tue, 14 Aug 2007 16:57:45 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7EKvgJ24829; Tue, 14 Aug 2007 20:57:42 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture - revised text on ECMP Date: Tue, 14 Aug 2007 16:57:42 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511B244B9@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A6@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture - revised text on ECMP Thread-Index: AcfaCU+NgYL9vlL2RBe24G2bEVtecAElm41g References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A6@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1948333357==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1948333357== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DEB5.C171DF56" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DEB5.C171DF56 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see my comment below denoted with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:13 PM To: pcn@ietf.org Subject: [PCN] PCN architecture - revised text on ECMP =20 This is to flag up that I wrote some revised text on ECMP (in Section 6, Design goals and challenges): =20 The following are open issues. They are taken from [I-D.briscoe-tsvwg-cl-architecture] which also describes some possible solutions (potential solutions are out of scope for this document). Note that some may be considered unimportant in general or in specific deployment scenarios. =20 =20 o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion is measured on a specific ingress-egress-aggregate. However, if the PCN-domain runs ECMP, then traffic on this ingress-egress- aggregate may follow several different paths - some of the paths could be pre-congested whilst others are not. There are two potential problems: [Joe] Actual there are 3 or 4 potential problems. [end] =20 1. over-admission: a new flow is admitted (because the pre- congestion level measured by the PCN-egress-node is sufficiently diluted by unmarked packets from non-congested paths that a new flow is admitted), but its packets travel through a pre-congested PCN-node [Joe] 2. under-admission: a new flow is blocked (because the pre-congestion level measured by the PCN-egress-node is sufficiently diluted by marked packets from pre-congested PCN-nodes that a new flow is blocked admission), but its packets would travel through a un-congested path. [end] =20 2. ineffective termination: flows are terminated, however their path doesn't travel through the (pre-)congested router(s). [Joe] The above requires that we only terminate marked flows. In the "Flow termination" section of the architecture draft there is no mention that only flows travelling through congested router(s) are to be terminated. I believe we need to add statement that only flows as indicated by packet(s) marking indicating passing over link(s) where the PCN-upper-rate was exceeded as requirement for ECMP. For flow termination to work with ECMP, only flows that pass over link(s) where PCN-upper-rate was exceeded should be terminated. =20 The overall PCN solution for flow termination must solve the second problem, since flow termination is a 'last resort'. For flow admission, the risk of slight over-admission may be acceptable (particularly with flow termination as a fall-back), at least for some operators. [Joe] I believe we should state that flow termination provides protection to the network should over-admission occur. However, over-admission followed by termination of some over-admitted flows is not desirable as it leads to dissatisfied users.=20 =20 =20 ------_=_NextPart_001_01C7DEB5.C171DF56 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see my comment below denoted = with [Joe].

 

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

From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:13 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture - revised text on ECMP

 

This is to flag up that I wrote = some revised text on ECMP (in Section 6, Design goals and = challenges):

 

   The following are open issues. =  They are taken from

   = [I-D.briscoe-tsvwg-cl-architecture] which also describes some

   possible solutions (potential = solutions are out of scope for this

   document).  Note that some = may be considered unimportant in general

   or in specific deployment = scenarios.

 

=  

   o  ECMP (Equal Cost = Multi-Path) Routing: The level of pre-congestion

      is measured on = a specific ingress-egress-aggregate.  However, = if

      the PCN-domain = runs ECMP, then traffic on this ingress-egress-

      aggregate may = follow several different paths - some of the paths

      could be = pre-congested whilst others are not.  There are two

      potential = problems:

[Joe] Actual = there are 3 or 4 potential problems. [end]

 

      1.  = over-admission: a new flow is admitted (because the pre-

       &nbs= p;  congestion level measured by the PCN-egress-node = is

       &nbs= p;  sufficiently diluted by unmarked packets from = non-congested

       &nbs= p;  paths that a new flow is admitted), but its packets = travel

       &nbs= p;  through a pre-congested PCN-node

[Joe] 2.  under-admission: a new flow is blocked (because the pre-congestion level measured by the PCN-egress-node is sufficiently diluted by marked = packets from pre-congested PCN-nodes that a new flow is blocked admission), but its packets would = travel through a un-congested path. [end]

 

      2.  = ineffective termination: flows are terminated, however = their

       &nbs= p;  path doesn't travel through the (pre-)congested = router(s).

[Joe] The above = requires that we only terminate marked flows. In the “Flow = termination” section of the architecture draft there is no mention that only flows = travelling through congested router(s) are to be terminated. I believe we need to = add statement that only flows as indicated by packet(s) marking indicating = passing over link(s) where the PCN-upper-rate was exceeded as requirement for ECMP. = For flow termination to work with ECMP, only flows that pass over link(s) where PCN-upper-rate was exceeded should be = terminated.

 

      The overall = PCN solution for flow termination must solve = the

      second = problem, since flow termination is a 'last resort'.  = For

      flow = admission, the risk of slight over-admission may be

      acceptable (particularly with flow termination as a fall-back), = at

      least for some operators.

[Joe] I believe = we should state that flow termination provides protection to the network should over-admission occur. However, over-admission followed by termination of = some over-admitted flows is not desirable as it leads to dissatisfied users. =

=  

 

------_=_NextPart_001_01C7DEB5.C171DF56-- --===============1948333357== 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://www1.ietf.org/mailman/listinfo/pcn --===============1948333357==-- From pcn-bounces@ietf.org Tue Aug 14 17:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL4M4-00061R-J7; Tue, 14 Aug 2007 17:55:12 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IL4M3-00061H-Tc for pcn-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 17:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL4M3-000618-5I for pcn@ietf.org; Tue, 14 Aug 2007 17:55:11 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL4M1-0007Fw-Fy for pcn@ietf.org; Tue, 14 Aug 2007 17:55:11 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B0A778BAE; Tue, 14 Aug 2007 23:55:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A31E98BEE; Tue, 14 Aug 2007 23:55:08 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3191F8BAE; Tue, 14 Aug 2007 23:55:04 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l7ELt3h01489; Tue, 14 Aug 2007 23:55:04 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 5CCB06F591; Tue, 14 Aug 2007 23:48:53 +0200 (CEST) Message-ID: <46C223F2.3000100@informatik.uni-wuerzburg.de> Date: Tue, 14 Aug 2007 23:51:46 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] PCN architecture new section on tunnelling References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A7@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB646511B2415D@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511B2415D@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, Imagine a packet is tunneled from node A to some other node B, it is=20 decapsulated there and forwarded to destination C. Then, the traffic=20 takes the route from A over B to C. 1st problem: how do we find the ingress node X of the packet at its PCN=20 egress Y? 2nd problem: provided that we know the ingress node X, the path from A=20 over B to C does not necessarily coincide with normal IP routed path=20 from the corresponding PCN ingress X to egress Y. If those packets are=20 admission marked, they may cause admission stop for traffic from X to Y=20 although they take a different path. Thus, the problem is that we associate the admission-stop-marking with=20 the path from the ingress to the egress of the packet. If the packet=20 took a different path than by typical IP routing, the interpretation of=20 the PCN information is leads to the wrong conclusions. Similar problems=20 occur with excess-traffic-marked packets if the corresponding PCN=20 information is associated with the path. The marked flow termination=20 (MFT) from the 3sm-draft associates the marking with the flow and can=20 cope well with arbitrarily routed flows. Possible solution: the marking from X to B needs to be evaluated at B=20 and be associated with the path from X to B, and the marking received=20 from B to Y needs to be evaluated at Y and be associated with the path=20 from B to Y. I just want to say: tunneling with tunnel endpoints in PCN networks is=20 not yet understood. Best wishes, Michael Jozef Babiarz wrote: > > Phil, please see my comment below demarked with [Joe]. > > /Regards, Joe/ > email:babiarz@nortel.com > Telephone:613-763-6098 > > -----------------------------------------------------------------------= - > > *From:* philip.eardley@bt.com [mailto:philip.eardley@bt.com] > *Sent:* August 8, 2007 6:14 PM > *To:* pcn@ietf.org > *Subject:* [PCN] PCN architecture new section on tunnelling > > This is to flag up that I wrote a new sub-section (in Section 5,=20 > Detailed functional architecture) about tunelling: > > 5.8. Tunnelling > > It is possible that tunnels terminate at a PCN-node. It is important > > that any PCN-marking is preserved after decapsulation, so that it is > > still seen by the PCN-egress-node. To ensure this, on decapsulation > > the following rules are applied: > > o the PCN-marking state of the inner and outer headers are compared > > o if the inner header's marking state is more severe then it is > > preserved > > o if the outer header's marking state is more severe then it is > > copied onto the inner header > > o NB the order of increasing severity is: unmarked; PCN-marking with > > first encoding (ie associated with the PCN-lower-rate); PCN- > > marking with second encoding (ie associated with the PCN-upper- > > rate) > > Similarly, if encapsulation is done within the PCN-domain, then the > > following rule is applied: > > =B7 any PCN-marking is copied into the outer header > > [Joe] The above may introduce unnecessary information leakage. Why not=20 > just at the encapsulation point mark all packets as unmarked. The=20 > decapsulation point can sort them out. Just realizes that excess rate=20 > marking approach will not work unless PCN-marking information is=20 > copied from inner to outer headers when encapsulating. [end] > > [Joe] I=92m assuming for time being that =93PCN nonce=94 (similar to EC= N=20 > nonce) is out of scope as we are not sure if it=92s need for PCN. If no= t=20 > than the =93PCN nonce=94 would also need to be copied to outer header. = [end] > > Tunnelling considerations also depend on which header bits the PCN WG > > decides to use. If the ECN bits are used then > > [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to > > its spirit. If the DSCP field is used then [RFC2983] needs to be > > considered carefully. > > An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to > > PCN-egress-nodes, in which case the rules above aren't needed. The > > potential reasons for doing such tunnelling are: the PCN-egress-node > > then automatically knows the address of the relevant PCN-ingress-node > > for a flow; even if ECMP is running, all PCN-packets on a particular > > ingress-egress-aggregate follow the same path. But it also has > > drawbacks: additional overhead in terms of bandwidth and processing; > > and the effective elimination of ECMP as a load balancing mechanism. > > -----------------------------------------------------------------------= - > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 15 03:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILDOw-0004vu-KN; Wed, 15 Aug 2007 03:34:46 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILDOv-0004vp-QD for pcn-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 03:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILDOr-0004vc-C8 for pcn@ietf.org; Wed, 15 Aug 2007 03:34:41 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILDOp-0004dS-Rg for pcn@ietf.org; Wed, 15 Aug 2007 03:34:41 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 08:34:38 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Wed, 15 Aug 2007 08:34:38 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DA@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <46BAF62B.1050002@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: Acfae0V9QP6nYXJzT1KqOBztsaA6uwEkxcXw From: To: X-OriginalArrivalTime: 15 Aug 2007 07:34:38.0604 (UTC) FILETIME=[BC5C24C0:01C7DF0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Yep, needs adding - at least for the second reason for probing (ECMP) phil > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 09 August 2007 12:11 > To: Eardley,PL,Philip,CXR9 R > Cc: PCN IETF list > Subject: Re: [PCN] PCN architecture, revised sub-section on probing >=20 > Hi Phil, >=20 > the text misses the fact that probing is more difficult in the presence > of ECMP. In this case, probe packets must have the same header as future > data packets to be routed on the same path in order to give answer > whether precongestion is on that path or not. This is an essential > aspect of probing and requires protocol standardization. >=20 > Regards, >=20 > Michael >=20 > philip.eardley@bt.com wrote: > > > > This is to flag up that I wrote a revised sub-section (in Section 5, > > Detailed functional architecture) about probing. to reflect > > (hopefully!) some other discussion we had on the list in july. > > > > > > > > 5.5. Probing functions > > > > > > > > Probing functions are optional, and can be used for admission > > > > control. A PCN-ingress-node generates and sends probe packets in > > > > order to test the pre-congestion level. Probing is useful or even > > > > essential under the following conditions: > > > > > > > > o when an ingress-egress-aggregate carries no traffic (or too little > > > > traffic for the PCN-egress-node to accurately make the > > > > "measurements of PCN-traffic" that are required for an admission > > > > decision). It may be that the traffic levels on other ingress- > > > > egress-aggregates are so high that a new flow shouldn't be > > > > admitted on the 'empty' ingress-egress-aggregate. Probing is > > > > useful to check this. > > > > > > > > o in the presence of multipath routing (ECMP) between the PCN- > > > > boundary-nodes, when some paths are pre-congested there may be > > > > other paths which aren't pre-congested. Probing is useful to > > > > determine whether the new flow would follow a path that isn't pre- > > > > congested and hence can be admitted. > > > > > > > > Probe packets may be simple data addressed to the PCN-egress-node and > > > > require no protocol standardisation, although there will be best > > > > practice for their number, size and rate. There are two > > > > possibilities for how probing is triggered: > > > > > > > > o the PCN-egress-node requests (signals) the PCN-ingress-node to > > > > generate probe traffic > > > > > > > > o if the PCN-ingress-node knows which PCN-egress-node is associated > > > > with the destination address in the admission request, then the > > > > PCN-ingress-node could know it has no reservation with that PCN- > > > > egress-node and unilaterally start probing. > > > > > > > > The probing functions are: > > > > > > > > o Make decision that probing is needed > > > > > > > > o (if required) Communicate the request that probing is needed - the > > > > PCN-egress-node signals to the PCN-ingress-node that probe traffic > > > > is needed > > > > > > > > o Generate probe traffic - the PCN-ingress-node generates the probe > > > > traffic. The appropriate number (or rate) of probe packets will > > > > depend on the PCN-marking algorithm; for example an excess-rate- > > > > marking algorithm generates fewer PCN-marks than a threshold- > > > > marking algorithm. > > > > > > > > o Forward probe packets - as far as PCN-interior-nodes are > > > > concerned, probe packets must be handled the same as (ordinary > > > > data) PCN-packets. > > > > > > > > o Consume probe packets - the PCN-egress-node consumes probe packets > > > > to ensure that they don't travel beyond the PCN-domain. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > >=20 > -- > 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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 15 04:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILDtq-0002ZK-Pd; Wed, 15 Aug 2007 04:06:42 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILDtp-0002ZF-Dj for pcn-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:06:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILDtp-0002Z7-1q for pcn@ietf.org; Wed, 15 Aug 2007 04:06:41 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILDtm-0005S5-PD for pcn@ietf.org; Wed, 15 Aug 2007 04:06:41 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:06:36 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Wed, 15 Aug 2007 09:06:35 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511A3E79C@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAA2mD2gAQq3rhA= From: To: , X-OriginalArrivalTime: 15 Aug 2007 08:06:36.0663 (UTC) FILETIME=[339CB870:01C7DF13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6944d3ce822583c9de35716021e61741 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0851585362==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0851585362== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF13.33262C80" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF13.33262C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-line phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 10 August 2007 18:28 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN architecture, revised sub-section on probing =20 Phil and all, my comments below are denoted by [Joe].=20 =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, revised sub-section on probing =20 This is to flag up that I wrote a revised sub-section (in Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some other discussion we had on the list in july.=20 =20 5.5. Probing functions =20 Probing functions are optional, and can be used for admission control. A PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level. Probing is useful or even essential under the following conditions: =20 [Joe] We need to decide if probing is optional or a mandatory function. I think that we agree that it's needed if there is ECMP or some other form of multipath routing.=20 =20 [phil] talking specifically about the multipath case for probing. yes I agree it's needed in principle. But it isn't clear to me whether you'd choose to use it in practice - it would mean you'd always probe for every call request, which could be a significant overhead & delay etc. perhaps it's better to take the slight risk that you over-admit; or even tunnel all data between ingress & egress (effectively turn off ecmp). To me it looks like an operational choice that isn't clear-cut.=20 =20 We also need probing when there is no traffic present between ingress - egress for an aggregate or when there is only one flow per ingress -egress.=20 [phil] yes =20 Probing is also very useful to verify that media path is present between ingress and egress before new flow is admitted. This is useful to avid the condition of a person answering the phone and having no audio path available.=20 =20 [phil] not sure I get this. at least if there's traffic present on ingress-egress-aggregate or probe gets through then this is ok. =20 When there are no tunnels between ingress-egress nodes, probing can be used to discover egress node and relay edge nodes address (more on this later). =20 =20 [phil] ok, I can imagine a probing mechanism might allow you to get this info. Seems too specific to mention in this section? =20 Finally, we are not sure if probing during admission of new flows would address issues of over admission or provide some mitigation against DoS attacks. We should have more information on this in few weeks.=20 =20 [phil] sounds good, look forward to hearing more! =20 On the other hand, probing is not need if we know that there is no ECMP or multipath routing in the network and all ingress - egress aggregates will have at least one flow present before pre-congestion occurs. So maybe in this section we should word it such that it explains when probing is needed and what problems it solves.=20 =20 [phil] I tried to word it like this! [end] =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision). It may be that the traffic levels on other ingress- egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. =20 [Joe] Agree that it's needed when there is no traffic between ingress-egress-aggregate. I also believe that probing should be very light weight, meaning that probing consume very little bandwidth in the network. [end] =20 o in the presence of multipath routing (ECMP) between the PCN- boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre- congested and hence can be admitted. =20 Probe packets may be simple data addressed to the PCN-egress-node and require no protocol standardisation, although there will be best practice for their number, size and rate. There are two possibilities for how probing is triggered: =20 [Joe] Probe packets need to have the same source/destination IP address, source/destination port number, protocol ID and DSCP value as media packets otherwise the network may route probe packets along a different path then media. [end] [phil] yes (at least for the ecmp case) =20 o the PCN-egress-node requests (signals) the PCN-ingress-node to generate probe traffic =20 [Joe] I'm assuming this is to address the case when there is no traffic flowing in a pre setup ingress-egress aggregate? Comment, it will not be needed if we probe during admission of new flows. [end] [phil]. Yes. This can be clarified.=20 =20 o if the PCN-ingress-node knows which PCN-egress-node is associated with the destination address in the admission request, then the PCN-ingress-node could know it has no reservation with that PCN- egress-node and unilaterally start probing. =20 [Joe] Do not understand how the PCN-ingress-node knows which PCN-egress-node the new flow that is going to be admitted will be routed through? Can you explain what you are thinking about here? [end] [phil] for example if it's seen the destination address before. Someone mentioned this case, bob I think.=20 =20 The probing functions are: =20 o Make decision that probing is needed =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed =20 [Joe] I think the PCN-ingress-node needs to trigger probing. For admission control, it has a lot more information then the egress node. The PCN-ingress-node has or needs to have source/destination IP address, source/destination port numbers, protocol ID and DSCP value of the flow that is to be admitted. Using this information the PCN-ingress-node sends probe packets marked with IP header information as the new flow will once admitted to discover which PCN-egress-node the new flow will go through. The PCN-egress-node needs to intercept the probe packets and send back to probe originating PCN-ingress-node the pre-congestion information of the path between ingress-egress. For bi-directional flows this needs to be done in both directions before admission decision is made. [end] [phil] I think we're talking at cross-purposes here, I agree with what you've written. I was thinking of the case of no traffic in ingress-egress-aggregate where it's the egress that realises this & tells the ingress to start probing. Bi-directional sessions are mentioned in Section 6 (not a probing specific issue). =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate- marking algorithm generates fewer PCN-marks than a threshold- marking algorithm. =20 [Joe] I do not think and from simulation I've seen to date that excess-rate-marking approach for admission control will work with probing. Excess-rate-marking requires a lot of packets to be received before any meaningful results can be obtained. [end] [phil] seems important to me to try and quantify this - is this something the simuations can get a handle on? should be added to list of comparison factors when we're choosing a marking algorithm. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 [Joe] Yes, the PCN-egress-node needs to consume probe packets. [end] =20 [Joe] Final note on probing and admission control. I've been exchanging emails with Michael Menth on this subject and we are planning to write a short draft that goes into more details in this area. Planning to send it out to the list in September time frame. [end] [phil] excellent! =20 ------_=_NextPart_001_01C7DF13.33262C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In-line

phil

 

-----Original Message-----
From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: 10 August 2007 18:28
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] PCN architecture, revised sub-section on probing

 

Phil and all, my = comments below are denoted by [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15 PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, revised sub-section on probing

 

This is to flag up that I wrote a revised sub-section (in = Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) = some other discussion we had on the list in july.

 

5.5.  Probing functions

 

   Probing functions are optional, and can be used for admission

   control.  A PCN-ingress-node generates and = sends probe packets in

   order to test the pre-congestion level.  = Probing is useful or even

   essential under the following = conditions:

 

[Joe] We need to decide if probing = is optional or a mandatory function. I think that we agree that it’s = needed if there is ECMP or some other form of multipath routing. =

 

[phil] talking specifically about the multipath case for probing. yes I agree = it’s needed in principle. But it isn’t clear to me whether you’d = choose to use it in practice – it would mean you’d always probe for = every call request, which could be a significant overhead & delay etc. = perhaps it’s better to take the slight risk that you over-admit; or even tunnel all = data between ingress & egress (effectively turn off ecmp). To me it looks = like an operational choice that isn’t clear-cut.

 

We also need probing when there is = no traffic present between ingress – egress for an aggregate or when = there is only one flow per ingress –egress.

[phil] = yes

 

Probing is also very useful to = verify that media path is present between ingress and egress before new flow is = admitted. This is useful to avid the condition of a person answering the phone and = having no audio path available.

 

[phil] not sure = I get this. at least if there’s traffic present on = ingress-egress-aggregate or probe gets through then this is ok.

 

When there are no tunnels between ingress-egress nodes, probing can be used to discover egress node and = relay edge nodes address (more on this later).  

 

[phil] ok, I can = imagine a probing mechanism might allow you to get this info. Seems too specific = to mention in this section?

 

Finally, we are not sure if = probing during admission of new flows would address issues of over admission or provide = some mitigation against DoS attacks. We should have more information on this = in few weeks.

 

[phil] sounds = good, look forward to hearing more!

 

On the other hand,  probing = is not need if we know that there is no ECMP or multipath routing in the = network and all ingress – egress aggregates will have at least one flow = present before pre-congestion occurs. So maybe in this section we should word it = such that it explains when probing is needed and what problems it solves. =

 

[phil] I tried = to word it like this!

[end]

 

   o  when an ingress-egress-aggregate carries no traffic (or too little

      traffic for the PCN-egress-node = to accurately make the

      "measurements of = PCN-traffic" that are required for an admission

      decision).  It may be that = the traffic levels on other ingress-

      egress-aggregates are so high = that a new flow shouldn't be

      admitted on the 'empty' ingress-egress-aggregate.  Probing is

      useful to check = this.

 

[Joe] Agree that it’s needed = when there is no traffic between ingress-egress-aggregate. I also believe = that probing should be very light weight, meaning that probing consume very = little bandwidth in the network. [end]

 

   o  in the presence of multipath routing (ECMP) between the PCN-

      boundary-nodes, when some paths = are pre-congested there may be

      other paths which aren't pre-congested.  Probing is useful to

      determine whether the new flow = would follow a path that isn't pre-

      congested and hence can be = admitted.

 

   Probe packets may be simple data addressed to the PCN-egress-node and

   require no protocol standardisation, although there = will be best

   practice for their number, size and rate.  = There are two

   possibilities for how probing is = triggered:

 

[Joe] Probe packets need to have = the same source/destination IP address, source/destination port number, protocol = ID and DSCP value as media packets otherwise the network may route probe = packets along a different path then media. [end]

[phil] yes (at = least for the ecmp case)

 

   o  the PCN-egress-node requests (signals) the = PCN-ingress-node to

      generate probe = traffic

 

[Joe] I’m assuming this is = to address the case when there is no traffic flowing in a pre setup ingress-egress aggregate? Comment, it will not be needed if we probe during admission = of new flows. [end]

[phil]. Yes. = This can be clarified.

 

   o  if the PCN-ingress-node knows which PCN-egress-node is associated

      with the destination address in = the admission request, then the

      PCN-ingress-node could know it = has no reservation with that PCN-

      egress-node and unilaterally = start probing.

 

[Joe] Do not understand how the PCN-ingress-node knows which PCN-egress-node the new flow that is going = to be admitted will be routed through? Can you explain what you are thinking = about here? [end]

[phil] for = example if it’s seen the destination address before. Someone mentioned this case, bob I = think.

 

   The probing functions are:

 

   o  Make decision that probing is = needed

 

   o  (if required) Communicate the request that = probing is needed - the

      PCN-egress-node signals to the PCN-ingress-node that probe traffic

      is needed

 

[Joe] I think the PCN-ingress-node = needs to trigger probing. For admission control, it has a lot more information = then the egress node. The PCN-ingress-node has or needs to have = source/destination IP address, source/destination port numbers, protocol ID and DSCP value of = the flow that is to be admitted. Using this information the PCN-ingress-node = sends probe packets marked with IP header information as the new flow will = once admitted to discover which PCN-egress-node the new flow will go through. = The PCN-egress-node needs to intercept the probe packets and send back to = probe originating PCN-ingress-node the pre-congestion information of the path = between ingress-egress. For bi-directional flows this needs to be done in both directions before admission decision is made. [end]

[phil] I think = we’re talking at cross-purposes here, I agree with what you’ve written. = I was thinking of the case of no traffic in ingress-egress-aggregate where = it’s the egress that realises this & tells the ingress to start probing. Bi-directional sessions are mentioned in Section 6 (not a probing = specific issue).

 

   o  Generate probe traffic - the = PCN-ingress-node generates the probe

      traffic.  The appropriate = number (or rate) of probe packets will

      depend on the PCN-marking = algorithm; for example an excess-rate-

      marking algorithm generates fewer PCN-marks than a threshold-

      marking = algorithm.

 

[Joe] I do not think and from = simulation I’ve seen to date that excess-rate-marking approach for admission = control will work with probing. Excess-rate-marking requires a lot of packets to = be received before any meaningful results can be obtained. = [end]

[phil] seems = important to me to try and quantify this – is this something the simuations can = get a handle on? should be added to list of comparison factors when = we’re choosing a marking algorithm.

 

   o  Forward probe packets - as far as PCN-interior-nodes are

      concerned, probe packets must be = handled the same as (ordinary

      data) = PCN-packets.

 

   o  Consume probe packets - the PCN-egress-node consumes probe packets

      to ensure that they don't travel = beyond the PCN-domain.

 

[Joe] Yes, the PCN-egress-node = needs to consume probe packets. [end]

 

[Joe] Final note on probing and = admission control. I’ve been exchanging emails with Michael Menth on this = subject and we are planning to write a short draft that goes into more details = in this area. Planning to send it out to the list in September time frame. = [end]

[phil] = excellent!

 

=00 ------_=_NextPart_001_01C7DF13.33262C80-- --===============0851585362== 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://www1.ietf.org/mailman/listinfo/pcn --===============0851585362==-- From pcn-bounces@ietf.org Wed Aug 15 04:14:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILE1g-0000A3-86; Wed, 15 Aug 2007 04:14:48 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILE1e-00009W-Ck for pcn-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 04:14:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILE1e-00009O-3G for pcn@ietf.org; Wed, 15 Aug 2007 04:14:46 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILE1c-0005cY-Fj for pcn@ietf.org; Wed, 15 Aug 2007 04:14:46 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 09:14:43 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WGscoping decisions in an RFC?) Date: Wed, 15 Aug 2007 09:14:43 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DC@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <5.2.1.1.2.20070810174236.0314abe0@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WGscoping decisions in an RFC?) Thread-Index: Acfbe49Y8L1MXEMmReG9vIjhsUHC8QDmBFig From: To: , X-OriginalArrivalTime: 15 Aug 2007 08:14:43.0574 (UTC) FILETIME=[55D57160:01C7DF14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Regardless of the precedence issue for emergency/military use, there still could be more than one PCN class. Ie can imagine an operator offering 2 services, "important inelastic flows with PCN adm ctrl" and "less important inelastic flows with PCN adm ctrl" The architecture draft (currently) says: o The PCN mechanisms may be applied to more than one traffic class (which are distinguished by DSCP). > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: 10 August 2007 18:14 > To: Jozef Babiarz > Cc: PCN IETF list > Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss > WGscoping decisions in an RFC?) >=20 > Joe, >=20 > At 01:03 10/08/2007, Jozef Babiarz wrote: > >Bob, Michael, > >In TSVWG about two years ago, it was decided that flow precedence > >information and control of it is to be handle in higher layers and not > >by the transport layer. > > > >I believe that if we have precedence and normal traffic in the network > >that admission and flow termination of it is handled based on precedence > >information that is provided via signalling (SIP) during session setup > >or higher layers control protocol. The transport layer and the PCN > >mechanism is not precedence aware. >=20 > What exactly do you mean by "the tsvwg decided"? I don't think the tsvwg > (or the IETF) is in a position to decide how emergency services define the > use of PHBs for emergencies. I would have thought this is an issue to be > decided by governments and operators and there's no big standards > implication whichever way they choose. Why would the IETF want or need to > force a government's or operator's choice in this respect? The whole point > of Diffserv is that the codepoints are there to be used as operators > choose, with some standard ones. >=20 > Certainly I believe the DoD don't like identifying precendence traffic in > the data plane, as it might make it easier to target an attack at certain > data. But the DoD is but a small part of the possible policy space in this > area. >=20 > In general, the IETF does vendor standards. If anyone was going to touch > operational policy standards in the hot policy area of emergency services, > I doubt very much it would be the IETF, which doesn't have the > political/voting structures necessary for such a politically sensitive > subject. Instead, I would imagine the IETF should produce protocols that > cater for what seems a reasonable spectrum of likely policy choices. >=20 > There does seem to be a valid technical motivation for specifying > precedence both at the session/signalling layer and in the data plane. > While a disaster or some emergency is in progress, routing and signalling > will be continually being disrupted and trying to stabilise, leading to > possibly continual excess traffic at various points in the data plane. > Even > if the emergency services have the right to signalling precedence over > other flows, if the emergency is characterised by persistent or continuing > disruption (earthquakes, riots, wars, DoS attacks etc), the emergency > media may well still be unintelligible for extended periods while > signalling is trying to deal with the storm. So in some operational > regimes, data priority might be needed as well as signalling priority. To > ensure precedence traffic floats on top of the persistently choppy waves > of > other traffic. >=20 > Even if there was data plane precedence, PCN would not have to be > precedence-aware. But when designing PCN we have to be aware of the > possible combinatorial codepoint expansion. If we insisted that PCN is > encoded in 3 DSCPs (say), then anyone that wanted to use n DSCPs for EF, > would have to set aside 3 x n DSCPs for PCN. >=20 > However, I admit, I know very little about operational practices or > regulatory/military/emergency/government requirements around the world in > this respect. I'm just saying it seems unlikely that every government in > the world will have agreed on a signalling-only approach to precedence. >=20 > Anyone have any facts? >=20 >=20 > Bob >=20 > >Regards, Joe > >email:babiarz@nortel.com > >Telephone:613-763-6098 > >-----Original Message----- > >From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >Sent: July 25, 2007 8:54 AM > >To: Bob Briscoe > >Cc: PCN IETF list > >Subject: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG > >scoping decisions in an RFC?) > > > >Hi Bob, > > > > > >Bob Briscoe wrote: > > >>> Regarding emergency use: the charter says: > > >>> > > >>> (D) flows may have different precedence, but the applicability > > >>> of the PCN mechanisms for emergency use (911, GETS, WPS, > > >>> MLPP, etc.) is out of scope > > >>> > > >>> This could be interpreted in more than one way, but I interpret this > >as > > >>> saying that PCN-specific mechanisms will not take flow precedence > >into > > >>> account. Which is a different than saying that PCN cannot be used > >with > > >>> flow setup protocols/mechanisms that take flow precedence into > >account. > > >>> > > >> > > >> As soon as we have multiple PCN classes it might be useful to think > > >> about flow precedence especially with regard to admission and > > >> termination priority. Equal treatment of flows means that a highly > > >> critical telemedicine application has the same probability to be > > >> terminated as a "relatively" uncritcical VoIP call in case of a > > >> disaster. I read the passage in the way that it's not our job to > > >> define mechanisms for emergency use, but it is not prohibited to > > >> extend PCN towards multiple classes with different requirements > > >> although this is not the first thing to do. > > > > > > Michael, just to warn against your use of the word 'extend' PCN. > > > > > > For the avoidance of doubt, I think Steve's saying it is NOT in scope > > > to extend PCN towards multiple classes with different requirements, > > > but it is in scope for PCN to use (ie refer out to) other mechanisms > > > that satisfy different emergency reqs, and similarly I guess it would > > > be in scope to prove PCN doesn't stop these other mechanisms working. > > > > > > If I'm right, the txt in this arch draft is misleading and should be > > > changed. The _applicability_ of PCN mechs for emergency use is in > > > scope, but PCN-specific mechs for emergency use are out of scope. > > > >Sorry for using the word "extend", but I'm not sure whether I understand > > > >your answer correctly. We had the discussion about coexistence of > >several PCN- and non-PCN classes already several times on the list and > >it seemed to me that is an unsolved issue so far. When I say "extend > >PCN" I mean adapting the currently discussed single-PCN-class mechanisms > > > >to work in a multi-class environment with a pre-defined number of PCN > >classes. I do not talk about extending PCN for the need of specific > >applications. > > > >The existence of multiple PCN classes has some impact on encoding and > >possibly also on metering and marking, so this is a question that should > > > >be discussed before encoding is decided. As far as I can remember the > >general view was that the charter does not forbid several PCN classes, > >but it's not the first thing to be done. Are we in line or is your view > >that there is and will be only a single PCN class that is coupled with a > > > >single PHB? Maybe this is an issue for discussion at the meeting, at > >least to me, the answer of that question is not clear. > > > >Regards, > > > >Michael > > > > > > > > > > > > > Bob > > > > > > > > >> Regards, > > >> > > >> Michael > > >> > > >>> > > >>> Regards, > > >>> > > >>> = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > >>> Steven Blake > > >>> Ericsson/Redback Networks +1 919-472-9913 > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> PCN mailing list > > >>> PCN@ietf.org > > >>> https://www1.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 > > > > > > > >_______________________________________________________________________ _ > >____ > > > > > > Bob Briscoe, Networks Research Centre, BT > > > Research > > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > > > 645196 > > > >-- > >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://www1.ietf.org/mailman/listinfo/pcn >=20 > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 >=20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 15 05:07:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEr5-0004yp-LA; Wed, 15 Aug 2007 05:07:55 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILEr4-0004yc-HX for pcn-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 05:07:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILEr4-0004yT-7G for pcn@ietf.org; Wed, 15 Aug 2007 05:07:54 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILEr1-0007S9-T6 for pcn@ietf.org; Wed, 15 Aug 2007 05:07:53 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 474BDAE48; Wed, 15 Aug 2007 11:07:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 395EAAE4B; Wed, 15 Aug 2007 11:07:49 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CC1E7AE4A; Wed, 15 Aug 2007 11:07:46 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l7F97kh04829; Wed, 15 Aug 2007 11:07:46 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id DCA296F591; Wed, 15 Aug 2007 11:01:35 +0200 (CEST) Message-ID: <46C2C19E.9000709@informatik.uni-wuerzburg.de> Date: Wed, 15 Aug 2007 11:04:30 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] PCN architecture, revised sub-section on probing References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DB@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DB@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, > o Generate probe traffic - the PCN-ingress-node generates the probe > > traffic. The appropriate number (or rate) of probe packets will > > depend on the PCN-marking algorithm; for example an excess-rate- > > marking algorithm generates fewer PCN-marks than a threshold- > > marking algorithm. > > [Joe] I do not think and from simulation I=92ve seen to date that=20 > excess-rate-marking approach for admission control will work with=20 > probing. Excess-rate-marking requires a lot of packets to be received=20 > before any meaningful results can be obtained. [end] > > [phil] seems important to me to try and quantify this =96 is this=20 > something the simuations can get a handle on? should be added to list=20 > of comparison factors when we=92re choosing a marking algorithm. > This does not even require simulations. Assume that "excess-rate"=20 marking is used for admission marking and admission is stopped if more=20 than 3% of the traffic is marked. Then, at least 33 packets are needed=20 for probing to admit a call. To obtain statistical reliability of 90%,=20 several hundred probes are required. Regards, Michael --=20 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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 15 14:26:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILNZj-0008SB-Bf; Wed, 15 Aug 2007 14:26:35 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILNZi-0008S6-Tx for pcn-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 14:26:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILNZi-0008Rw-IQ for pcn@ietf.org; Wed, 15 Aug 2007 14:26:34 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILNZh-0003OH-SM for pcn@ietf.org; Wed, 15 Aug 2007 14:26:34 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7FIQU211771; Wed, 15 Aug 2007 18:26:30 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, new addressing sub-section Date: Wed, 15 Aug 2007 14:26:16 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511B7A93E@zcarhxm1.corp.nortel.com> In-Reply-To: <00c701c7dd73$b3409480$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, new addressing sub-section Thread-Index: Acfdc7r2ri2gV9RnQA+fOrJNSfkvNQB9Aimw References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A8@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB646511A3EA6B@zcarhxm1.corp.nortel.com> <00c701c7dd73$b3409480$864c460a@china.huawei.com> From: "Jozef Babiarz" To: "Tina TSOU" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d482d1c72628b52d66564c4b21944e Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0078204631==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0078204631== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF69.C43850C6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF69.C43850C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See additional comments demarked with [Joe1] below. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: August 13, 2007 2:32 AM To: pcn@ietf.org; philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03) Subject: Re: [PCN] PCN architecture, new addressing sub-section =20 =20 ----- Original Message -----=20 From: Jozef Babiarz =20 To: philip.eardley@bt.com ; pcn@ietf.org=20 Sent: Saturday, August 11, 2007 4:52 AM Subject: RE: [PCN] PCN architecture, new addressing sub-section =20 See my comments below demarked with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, new addressing sub-section =20 This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about addressing: =20 5.7. Addressing =20 PCN-nodes may need to know the address of other PCN-nodes: =20 o in all cases PCN-interior-nodes don't need to know the address of any other PCN-nodes, except their next hop neighbours =20 o in the cases of admission or termination decision by a PCN- boundary-node, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, at a minimum so that the PCN-ingress-node can be informed to enforce the admission decision through policing. The addressing information can be gathered from signalling, for example as described for RSVP in [I-D.lefaucheur-rsvp-ecn]. Alternatively, if PCN-traffic is always tunnelled across the PCN-domain, then the PCN-ingress- node's address is simply the source address of the outer packet header. [Joe] I believe that the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified "... enforce the admission and flow termination decision through policing." [end] [Tina: sounds excellent.] =20 [Joe] Would also like to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. "Another method that may be used to discover and exchange address information between PCN-boundary-nodes is through probing. The PCN-ingerss-node using the IP header information of the flow to be admitted generates and sends probe packets that can easily be detected by the PCN-egress-node. The sent probe packets contain as payload the address of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow." [end] [Tina: I found there is similarity between this probe method and RSVP method. The PCN ingress node places its address in the probe packet or RSVP PATH message, the interior nodes doesn't care about these packets, the PCN egress node could associate the flow with the correct PCN ingress node after extracting the address of the PCN ingress node embedded in the probe packet or RSVP PATH message. These kinds of methods have a disadvantage: it's hard for the egress node to merge the flows. A PCN egress node may create a mapping table like follows: [Joe1] I do not see a need to merge flows in egress node for admission control if probing is used. Also, no need to build and maintain ingress-egress flow aggregating tables or perform rate measurements of marked or unmarked PCN traffic if the marking as in 3sm draft is used. [end] =09 FLOW FLOW's Ingress node flow1 Ingress A flow2 Ingress A flow3 Ingress B flow4 Ingress B If there are too many flows, the table may be very large. One option to solve addressing of PCN-boundary node may be to use symmetric route. For example, supposing IBGP is running on the PCN-boundary node: 1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress B----2.2.2.0/24 IBGP could tell the egress node B that it has to go through PCN ingress A to reach 1.1.1.0/24, the egress node B could then regard a packet from 1.1.1.0/24 will come through ingress A, given a symmetric route scenario. The disadvantage of this option may be the requirement of symmetric route. The advantage of this option is that merged table item may be supported. Network Network's Ingress node 1.1.1.0/24 Ingress A]=20 =20 o in the cases of admission or termination decision by a central control node, the PCN-egress-node needs to be configured with the address of the centralised node. In addition, depending on the exact deployment scenario and its signalling, the centralised node may need to know the addresses of the PCN-ingress-node and PCN- egress-node, and the PCN-egress-node know the address of the PCN- ingress-node. NOTE: Consideration of the centralised case is out of scope of the initial PCN WG Charter. =20 [Joe] I think we need a bit more discussion about the central control node. I'm thinking of something like a PDP where pre-congestion information is sent to and after verifying the policy the result is sent to PCN-ingress-node to care out the action. For this scenario, the PCN-boundary-nodes need to be provisioned with the address of the central policy control node. [end] =20 [Joe] Can the proponents of the central control node expand a bit more on how this will work? [end] [Tina: A centralized node will not burden the addressing of PCN-boundary nodes. To make metering, the egress node always has to know the ingress node address a flow associated. A centralized node makes the egress node doesn't need to notify the pre-congestion information (CLE) to the ingress node, instead, the egress node will send it to the centralized node. So the address of the centralized node has to be provisioned on the egress node. When the egress node notifies the CLE to the centralized node, it has to send the ingress node address associated the CLE. So the centralized would know the address of every PCN boundary node.] =20 (I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder if the description of the centralised node case is too long, as the case is strictly out of scope.) =20 =20 =09 ________________________________ _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C7DF69.C43850C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See additional comments demarked = with [Joe1] below.

 

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

From: Tina = TSOU [mailto:tena@huawei.com]
Sent: August 13, 2007 = 2:32 AM
To: pcn@ietf.org; philip.eardley@bt.com; Babiarz, = Jozef (CAR:0S03)
Subject: Re: [PCN] PCN architecture, new addressing sub-section

 

 

----- Original Message ----- =

Sent: = Saturday, August 11, 2007 4:52 AM

Subject: RE: = [PCN] PCN architecture, new addressing sub-section

 

See my comments below demarked with = [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, new addressing sub-section

 

This is to flag up that I wrote = a new sub-section (in Section 5, Detailed functional architecture) about = addressing:

 

5.7.  = Addressing

 

   PCN-nodes may need to know the = address of other PCN-nodes:

 

   o  in all cases = PCN-interior-nodes don't need to know the address of

      any other = PCN-nodes, except their next hop neighbours

 

   o  in the cases of = admission or termination decision by a PCN-

      boundary-node, = the PCN-egress-node needs to know the address = of

      the = PCN-ingress-node associated with a flow, at a minimum so = that

      the = PCN-ingress-node can be informed to enforce the admission

      decision = through policing.  The addressing information can = be

      gathered from signalling, for example as described for RSVP = in

      [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic = is

      always = tunnelled across the PCN-domain, then the PCN-ingress-

      node's address = is simply the source address of the outer = packet

      = header.

[Joe] I believe that = the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified “... = enforce the admission and flow termination decision through policing.” = [end]

[Tina: sounds excellent.]

 

[Joe] Would also like = to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. “Another method that may be used to discover = and exchange address information between PCN-boundary-nodes is through = probing. The PCN-ingerss-node using the IP header information of the flow to be = admitted generates and sends probe packets that can easily be detected by the PCN-egress-node. The sent probe packets contain as payload the address = of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow.” = [end]

[Tina: I found = there is similarity between this probe method and RSVP method. The PCN ingress = node places its address in the probe packet or RSVP PATH message, the = interior nodes doesn't care about these packets, the PCN egress node could associate = the flow with the correct PCN ingress node after extracting the address of the = PCN ingress node embedded in the probe packet or RSVP PATH message.
These kinds of methods have a disadvantage: it's hard for the egress = node to merge the flows. A PCN egress node may create a mapping table like = follows:

[Joe1] I do not = see a need to merge flows in egress node for admission control if probing is = used. Also, no need to build and maintain ingress-egress flow aggregating tables or = perform rate measurements of marked or unmarked PCN traffic if the marking as in = 3sm draft is used. [end]


FLOW    FLOW's Ingress node
flow1    Ingress A
flow2    Ingress A
flow3    Ingress B
flow4    Ingress B
If there are too many flows, the table may be very large.
One option to solve addressing of PCN-boundary node may be to use = symmetric route. For example, supposing IBGP is running on the PCN-boundary = node:
1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress = B----2.2.2.0/24
IBGP could tell the egress node B that it has to go through PCN ingress = A to reach 1.1.1.0/24, the egress node B could then regard a packet from = 1.1.1.0/24 will come through ingress A, given a symmetric route scenario.
The disadvantage of this option may be the requirement of symmetric = route. The advantage of this option is that merged table item may be supported.
Network   Network's Ingress node
1.1.1.0/24   Ingress A] 

 

   o  in the cases of = admission or termination decision by a central

      control node, = the PCN-egress-node needs to be configured with = the

      address of the centralised node.  In addition, depending on = the

      exact = deployment scenario and its signalling, the centralised = node

      may need to = know the addresses of the PCN-ingress-node and PCN-

      egress-node, = and the PCN-egress-node know the address of the = PCN-

      = ingress-node.  NOTE: Consideration of the centralised case is = out

      of scope of = the initial PCN WG Charter.

 

[Joe] I think we need = a bit more discussion about the central control node. I’m thinking of = something like a PDP where pre-congestion information is sent to and after verifying = the policy the result is sent to PCN-ingress-node to care out the action. For this scenario, the PCN-boundary-nodes need to be provisioned with the address = of the central policy control node. [end]

 

=

[Joe] Can the = proponents of the central control node expand a bit more on how this will = work? [end]

[Tina: A centralized node will not burden the addressing of PCN-boundary nodes. To make metering, the egress node always has to know = the ingress node address a flow associated. A centralized node makes the = egress node doesn’t need to notify the pre-congestion information (CLE) = to the ingress node, instead, the egress node will send it to the centralized = node. So the address of the centralized node has to be provisioned on the egress = node. When the egress node notifies the CLE to the centralized node, it has to = send the ingress node address associated the CLE. So the centralized would = know the address of every PCN boundary node.]

 

(I'm not completely happy with it. I'm not = sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder = if the description of the centralised node case is too long, as the case is = strictly out of scope.)

 

 

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn

------_=_NextPart_001_01C7DF69.C43850C6-- --===============0078204631== 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://www1.ietf.org/mailman/listinfo/pcn --===============0078204631==-- From pcn-bounces@ietf.org Wed Aug 15 16:14:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPGI-0005md-KC; Wed, 15 Aug 2007 16:14:38 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILPGH-0005mY-BN for pcn-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 16:14:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPGF-0005mO-MS for pcn@ietf.org; Wed, 15 Aug 2007 16:14:37 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILPGA-0006zr-5H for pcn@ietf.org; Wed, 15 Aug 2007 16:14:35 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7FKERQ13463; Wed, 15 Aug 2007 20:14:27 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture new section on tunnelling Date: Wed, 15 Aug 2007 16:14:26 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511B7AB37@zcarhxm1.corp.nortel.com> In-Reply-To: <46C223F2.3000100@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture new section on tunnelling Thread-Index: AcfevcwTuELc9KMoQTKhwwRxzjdP4gAtc8CQ References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A7@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB646511B2415D@zcarhxm1.corp.nortel.com> <46C223F2.3000100@informatik.uni-wuerzburg.de> From: "Jozef Babiarz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org See my comments below demarked with [Joe] Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: August 14, 2007 5:52 PM To: Babiarz, Jozef (CAR:0S03) Cc: philip.eardley@bt.com; pcn@ietf.org Subject: Re: [PCN] PCN architecture new section on tunnelling Hi, Imagine a packet is tunneled from node A to some other node B, it is=20 decapsulated there and forwarded to destination C. Then, the traffic=20 takes the route from A over B to C. 1st problem: how do we find the ingress node X of the packet at its PCN=20 egress Y? [Joe] One possible approach is to use a probe method something like. PCN-ingress node using the IP header information of the flow to be admitted generates and sends probe packets that can easily be detected by the PCN-egress-node (in your case node C). The sent probe packets contain as payload the address of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow. [end] 2nd problem: provided that we know the ingress node X, the path from A=20 over B to C does not necessarily coincide with normal IP routed path=20 from the corresponding PCN ingress X to egress Y. [Joe] It will coincide if the IP header information of the probe packet is the same as media packet if admitted. By IP header information I mean, source/destination IP address, source/destination port numbers, protocol ID and DSCP value. The source/destination IP address, etc. is that of endpoints and not boundary nodes that originate or consume probe packets.[end] If those packets are=20 admission marked, they may cause admission stop for traffic from X to Y=20 although they take a different path. Thus, the problem is that we associate the admission-stop-marking with=20 the path from the ingress to the egress of the packet. If the packet=20 took a different path than by typical IP routing, the interpretation of=20 the PCN information is leads to the wrong conclusions. Similar problems=20 occur with excess-traffic-marked packets if the corresponding PCN=20 information is associated with the path. The marked flow termination=20 (MFT) from the 3sm-draft associates the marking with the flow and can=20 cope well with arbitrarily routed flows. Possible solution: the marking from X to B needs to be evaluated at B=20 and be associated with the path from X to B, and the marking received=20 from B to Y needs to be evaluated at Y and be associated with the path=20 from B to Y. [Joe] Not sure way the marking at B needs to be evaluated? At the decapsulation point B, if the outer header's marking state is more severe then it is copied onto the inner header. [end] I just want to say: tunneling with tunnel endpoints in PCN networks is=20 not yet understood. Best wishes, Michael Jozef Babiarz wrote: > > Phil, please see my comment below demarked with [Joe]. > > /Regards, Joe/ > email:babiarz@nortel.com > Telephone:613-763-6098 > > ------------------------------------------------------------------------ > > *From:* philip.eardley@bt.com [mailto:philip.eardley@bt.com] > *Sent:* August 8, 2007 6:14 PM > *To:* pcn@ietf.org > *Subject:* [PCN] PCN architecture new section on tunnelling > > This is to flag up that I wrote a new sub-section (in Section 5,=20 > Detailed functional architecture) about tunelling: > > 5.8. Tunnelling > > It is possible that tunnels terminate at a PCN-node. It is important > > that any PCN-marking is preserved after decapsulation, so that it is > > still seen by the PCN-egress-node. To ensure this, on decapsulation > > the following rules are applied: > > o the PCN-marking state of the inner and outer headers are compared > > o if the inner header's marking state is more severe then it is > > preserved > > o if the outer header's marking state is more severe then it is > > copied onto the inner header > > o NB the order of increasing severity is: unmarked; PCN-marking with > > first encoding (ie associated with the PCN-lower-rate); PCN- > > marking with second encoding (ie associated with the PCN-upper- > > rate) > > Similarly, if encapsulation is done within the PCN-domain, then the > > following rule is applied: > > * any PCN-marking is copied into the outer header > > [Joe] The above may introduce unnecessary information leakage. Why not > just at the encapsulation point mark all packets as unmarked. The=20 > decapsulation point can sort them out. Just realizes that excess rate=20 > marking approach will not work unless PCN-marking information is=20 > copied from inner to outer headers when encapsulating. [end] > > [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN=20 > nonce) is out of scope as we are not sure if it's need for PCN. If not > than the "PCN nonce" would also need to be copied to outer header. [end] > > Tunnelling considerations also depend on which header bits the PCN WG > > decides to use. If the ECN bits are used then > > [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to > > its spirit. If the DSCP field is used then [RFC2983] needs to be > > considered carefully. > > An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to > > PCN-egress-nodes, in which case the rules above aren't needed. The > > potential reasons for doing such tunnelling are: the PCN-egress-node > > then automatically knows the address of the relevant PCN-ingress-node > > for a flow; even if ECMP is running, all PCN-packets on a particular > > ingress-egress-aggregate follow the same path. But it also has > > drawbacks: additional overhead in terms of bandwidth and processing; > > and the effective elimination of ECMP as a load balancing mechanism. > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 15 17:10:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILQ8H-0006kw-DG; Wed, 15 Aug 2007 17:10:25 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILQ8G-0006eR-8O for pcn-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 17:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILQ8F-0006bL-L1 for pcn@ietf.org; Wed, 15 Aug 2007 17:10:23 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILQ8D-0001wI-Q2 for pcn@ietf.org; Wed, 15 Aug 2007 17:10:23 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7FLAJ219107; Wed, 15 Aug 2007 21:10:19 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Wed, 15 Aug 2007 17:10:03 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511B7AC07@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DB@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAA2mD2gAQq3rhAAG+GTsA== References: <9671A92C3C8B5744BC97F855F7CB646511A3E79C@zcarhxm1.corp.nortel.com> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DB@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: e0bbc813800de05a47ebd213c9581535 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0300807196==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0300807196== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF80.A60D306E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF80.A60D306E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See two comments in line marked with [Joe1] =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 15, 2007 4:07 AM To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org Subject: RE: [PCN] PCN architecture, revised sub-section on probing =20 In-line phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 10 August 2007 18:28 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN architecture, revised sub-section on probing =20 Phil and all, my comments below are denoted by [Joe].=20 =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, revised sub-section on probing =20 This is to flag up that I wrote a revised sub-section (in Section 5, Detailed functional architecture) about probing. to reflect (hopefully!) some other discussion we had on the list in july.=20 =20 5.5. Probing functions =20 Probing functions are optional, and can be used for admission control. A PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level. Probing is useful or even essential under the following conditions: =20 [Joe] We need to decide if probing is optional or a mandatory function. I think that we agree that it's needed if there is ECMP or some other form of multipath routing.=20 =20 [phil] talking specifically about the multipath case for probing. yes I agree it's needed in principle. But it isn't clear to me whether you'd choose to use it in practice - it would mean you'd always probe for every call request, which could be a significant overhead & delay etc. perhaps it's better to take the slight risk that you over-admit; or even tunnel all data between ingress & egress (effectively turn off ecmp). To me it looks like an operational choice that isn't clear-cut.=20 [Joe1] I see your point. Maybe we need to state under what conditions probing should be used and let the operator decide.=20 =20 We also need probing when there is no traffic present between ingress - egress for an aggregate or when there is only one flow per ingress -egress.=20 [phil] yes =20 Probing is also very useful to verify that media path is present between ingress and egress before new flow is admitted. This is useful to avid the condition of a person answering the phone and having no audio path available.=20 =20 [phil] not sure I get this. at least if there's traffic present on ingress-egress-aggregate or probe gets through then this is ok. [Joe1] Yes. This is useful when there is no traffic in the aggregate or if the solution does not relay on ingress-egress aggregate and has higher importance when we get into multi-domain configurations.=20 =20 When there are no tunnels between ingress-egress nodes, probing can be used to discover egress node and relay edge nodes address (more on this later). =20 =20 [phil] ok, I can imagine a probing mechanism might allow you to get this info. Seems too specific to mention in this section? =20 Finally, we are not sure if probing during admission of new flows would address issues of over admission or provide some mitigation against DoS attacks. We should have more information on this in few weeks.=20 =20 [phil] sounds good, look forward to hearing more! =20 On the other hand, probing is not need if we know that there is no ECMP or multipath routing in the network and all ingress - egress aggregates will have at least one flow present before pre-congestion occurs. So maybe in this section we should word it such that it explains when probing is needed and what problems it solves.=20 =20 [phil] I tried to word it like this! [end] =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision). It may be that the traffic levels on other ingress- egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. =20 [Joe] Agree that it's needed when there is no traffic between ingress-egress-aggregate. I also believe that probing should be very light weight, meaning that probing consume very little bandwidth in the network. [end] =20 o in the presence of multipath routing (ECMP) between the PCN- boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre- congested and hence can be admitted. =20 Probe packets may be simple data addressed to the PCN-egress-node and require no protocol standardisation, although there will be best practice for their number, size and rate. There are two possibilities for how probing is triggered: =20 [Joe] Probe packets need to have the same source/destination IP address, source/destination port number, protocol ID and DSCP value as media packets otherwise the network may route probe packets along a different path then media. [end] [phil] yes (at least for the ecmp case) =20 o the PCN-egress-node requests (signals) the PCN-ingress-node to generate probe traffic =20 [Joe] I'm assuming this is to address the case when there is no traffic flowing in a pre setup ingress-egress aggregate? Comment, it will not be needed if we probe during admission of new flows. [end] [phil]. Yes. This can be clarified.=20 =20 o if the PCN-ingress-node knows which PCN-egress-node is associated with the destination address in the admission request, then the PCN-ingress-node could know it has no reservation with that PCN- egress-node and unilaterally start probing. =20 [Joe] Do not understand how the PCN-ingress-node knows which PCN-egress-node the new flow that is going to be admitted will be routed through? Can you explain what you are thinking about here? [end] [phil] for example if it's seen the destination address before. Someone mentioned this case, bob I think.=20 =20 The probing functions are: =20 o Make decision that probing is needed =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed =20 [Joe] I think the PCN-ingress-node needs to trigger probing. For admission control, it has a lot more information then the egress node. The PCN-ingress-node has or needs to have source/destination IP address, source/destination port numbers, protocol ID and DSCP value of the flow that is to be admitted. Using this information the PCN-ingress-node sends probe packets marked with IP header information as the new flow will once admitted to discover which PCN-egress-node the new flow will go through. The PCN-egress-node needs to intercept the probe packets and send back to probe originating PCN-ingress-node the pre-congestion information of the path between ingress-egress. For bi-directional flows this needs to be done in both directions before admission decision is made. [end] [phil] I think we're talking at cross-purposes here, I agree with what you've written. I was thinking of the case of no traffic in ingress-egress-aggregate where it's the egress that realises this & tells the ingress to start probing. Bi-directional sessions are mentioned in Section 6 (not a probing specific issue). =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate- marking algorithm generates fewer PCN-marks than a threshold- marking algorithm. =20 [Joe] I do not think and from simulation I've seen to date that excess-rate-marking approach for admission control will work with probing. Excess-rate-marking requires a lot of packets to be received before any meaningful results can be obtained. [end] [phil] seems important to me to try and quantify this - is this something the simuations can get a handle on? should be added to list of comparison factors when we're choosing a marking algorithm. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 [Joe] Yes, the PCN-egress-node needs to consume probe packets. [end] =20 [Joe] Final note on probing and admission control. I've been exchanging emails with Michael Menth on this subject and we are planning to write a short draft that goes into more details in this area. Planning to send it out to the list in September time frame. [end] [phil] excellent! =20 ------_=_NextPart_001_01C7DF80.A60D306E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See two = comments in line marked with [Joe1]

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 15, 2007 = 4:07 AM
To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org
Subject: RE: [PCN] PCN architecture, revised sub-section on = probing

 

In-line

phil

 

-----Original Message-----
From: Jozef Babiarz = [mailto:babiarz@nortel.com]
Sent: 10 August 2007 = 18:28
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] PCN architecture, revised sub-section on probing

 

Phil and all, my comments below are denoted by [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, revised sub-section on probing

 

This is to flag up that I wrote a revised = sub-section (in Section 5, Detailed functional architecture) about probing. to = reflect (hopefully!) some other discussion we had on the list in july. =

 

5.5.  Probing = functions

 

   Probing functions are optional, = and can be used for admission

   control.  A = PCN-ingress-node generates and sends probe packets in

   order to test the pre-congestion level.  Probing is useful or even

   essential under the following = conditions:

 

[Joe] We need to = decide if probing is optional or a mandatory function. I think that we agree that it’s needed if there is ECMP or some other form of multipath = routing.

 

[phil] talking specifically about the multipath case for probing. yes I agree = it’s needed in principle. But it isn’t clear to me whether you’d = choose to use it in practice – it would mean you’d always probe for = every call request, which could be a significant overhead & delay etc. = perhaps it’s better to take the slight risk that you over-admit; or even = tunnel all data between ingress & egress (effectively turn off ecmp). To me = it looks like an operational choice that isn’t clear-cut. =

[Joe1] I see = your point. Maybe we need to state under what conditions probing should be = used and let the operator decide.

 

We also need probing = when there is no traffic present between ingress – egress for an aggregate or = when there is only one flow per ingress –egress.

[phil] = yes

 

Probing is also very = useful to verify that media path is present between ingress and egress before new = flow is admitted. This is useful to avid the condition of a person answering the = phone and having no audio path available.

 

[phil] not sure = I get this. at least if there’s traffic present on = ingress-egress-aggregate or probe gets through then this is ok.

[Joe1] Yes. = This is useful when there is no traffic in the aggregate or if the solution does not = relay on ingress-egress aggregate and has higher importance when we get into = multi-domain configurations.

 

When there are no = tunnels between ingress-egress nodes, probing can be used to discover egress = node and relay edge nodes address (more on this later).  

 

[phil] ok, I can = imagine a probing mechanism might allow you to get this info. Seems too specific = to mention in this section?

 

Finally, we are not = sure if probing during admission of new flows would address issues of over = admission or provide some mitigation against DoS attacks. We should have more = information on this in few weeks.

 

[phil] sounds = good, look forward to hearing more!

 

On the other hand, =  probing is not need if we know that there is no ECMP or multipath routing in the network and all ingress – egress aggregates will have at least one = flow present before pre-congestion occurs. So maybe in this section we should = word it such that it explains when probing is needed and what problems it = solves.

 

[phil] I tried = to word it like this!

[end]

 

   o  when an = ingress-egress-aggregate carries no traffic (or too little

      traffic for = the PCN-egress-node to accurately make the

      = "measurements of PCN-traffic" that are required for an = admission

      = decision).  It may be that the traffic levels on other = ingress-

      = egress-aggregates are so high that a new flow shouldn't be

      admitted on = the 'empty' ingress-egress-aggregate.  Probing is

      useful to = check this.

 

[Joe] Agree that = it’s needed when there is no traffic between ingress-egress-aggregate. I also believe that probing should be very light weight, meaning that probing = consume very little bandwidth in the network. [end]

 

   o  in the presence of = multipath routing (ECMP) between the PCN-

      = boundary-nodes, when some paths are pre-congested there may be

      other paths = which aren't pre-congested.  Probing is useful = to

      determine = whether the new flow would follow a path that isn't = pre-

      congested and = hence can be admitted.

 

   Probe packets may be simple data addressed to the PCN-egress-node and

   require no protocol = standardisation, although there will be best

   practice for their number, size = and rate.  There are two

   possibilities for how probing is triggered:

 

[Joe] Probe packets = need to have the same source/destination IP address, source/destination port number, protocol ID and DSCP value as media packets otherwise the network may = route probe packets along a different path then media. = [end]

[phil] yes (at = least for the ecmp case)

 

   o  the PCN-egress-node = requests (signals) the PCN-ingress-node to

      generate probe = traffic

 

[Joe] I’m = assuming this is to address the case when there is no traffic flowing in a pre setup ingress-egress aggregate? Comment, it will not be needed if we probe = during admission of new flows. [end]

[phil]. Yes. = This can be clarified.

 

   o  if the PCN-ingress-node = knows which PCN-egress-node is associated

      with the = destination address in the admission request, then the

      = PCN-ingress-node could know it has no reservation with that PCN-

      egress-node = and unilaterally start probing.

 

[Joe] Do not = understand how the PCN-ingress-node knows which PCN-egress-node the new flow that is going = to be admitted will be routed through? Can you explain what you are thinking = about here? [end]

[phil] for = example if it’s seen the destination address before. Someone mentioned this = case, bob I think.

 

   The probing functions = are:

 

   o  Make decision that = probing is needed

 

   o  (if required) = Communicate the request that probing is needed - the

      = PCN-egress-node signals to the PCN-ingress-node that probe traffic

      is = needed

 

[Joe] I think the PCN-ingress-node needs to trigger probing. For admission control, it has = a lot more information then the egress node. The PCN-ingress-node has or needs = to have source/destination IP address, source/destination port numbers, = protocol ID and DSCP value of the flow that is to be admitted. Using this = information the PCN-ingress-node sends probe packets marked with IP header = information as the new flow will once admitted to discover which PCN-egress-node the = new flow will go through. The PCN-egress-node needs to intercept the probe = packets and send back to probe originating PCN-ingress-node the pre-congestion = information of the path between ingress-egress. For bi-directional flows this needs = to be done in both directions before admission decision is made. = [end]

[phil] I think we’re talking at cross-purposes here, I agree with what = you’ve written. I was thinking of the case of no traffic in = ingress-egress-aggregate where it’s the egress that realises this & tells the ingress = to start probing. Bi-directional sessions are mentioned in Section 6 (not a = probing specific issue).

 

   o  Generate probe traffic - = the PCN-ingress-node generates the probe

      traffic.  = The appropriate number (or rate) of probe packets = will

      depend on the PCN-marking algorithm; for example an = excess-rate-

      marking = algorithm generates fewer PCN-marks than a threshold-

      marking = algorithm.

 

[Joe] I do not think = and from simulation I’ve seen to date that excess-rate-marking approach for admission control will work with probing. Excess-rate-marking requires a = lot of packets to be received before any meaningful results can be obtained. = [end]

[phil] seems = important to me to try and quantify this – is this something the simuations can = get a handle on? should be added to list of comparison factors when = we’re choosing a marking algorithm.

 

   o  Forward probe packets - = as far as PCN-interior-nodes are

      concerned, = probe packets must be handled the same as = (ordinary

      data) = PCN-packets.

 

   o  Consume probe packets - = the PCN-egress-node consumes probe packets

      to ensure that = they don't travel beyond the PCN-domain.

 

[Joe] Yes, the = PCN-egress-node needs to consume probe packets. [end]

 

[Joe] Final note on = probing and admission control. I’ve been exchanging emails with Michael Menth = on this subject and we are planning to write a short draft that goes into more = details in this area. Planning to send it out to the list in September time = frame. [end]

[phil] = excellent!

 

------_=_NextPart_001_01C7DF80.A60D306E-- --===============0300807196== 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://www1.ietf.org/mailman/listinfo/pcn --===============0300807196==-- From pcn-bounces@ietf.org Thu Aug 16 17:39:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILn3q-0007tI-W9; Thu, 16 Aug 2007 17:39:23 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ILn3p-0007tC-OB for pcn-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 17:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILn3p-0007t4-EW for pcn@ietf.org; Thu, 16 Aug 2007 17:39:21 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILn3n-0004oA-Nf for pcn@ietf.org; Thu, 16 Aug 2007 17:39:21 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DA415ABE6; Thu, 16 Aug 2007 23:39:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id CCB7CACA2; Thu, 16 Aug 2007 23:39:14 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 6A5F6ABE6; Thu, 16 Aug 2007 23:39:12 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l7GLdCh17852; Thu, 16 Aug 2007 23:39:12 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 4F9C76F591; Thu, 16 Aug 2007 23:32:59 +0200 (CEST) Message-ID: <46C4C33A.7050704@informatik.uni-wuerzburg.de> Date: Thu, 16 Aug 2007 23:35:54 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] PCN architecture new section on tunnelling References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A7@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB646511B2415D@zcarhxm1.corp.nortel.com> <46C223F2.3000100@informatik.uni-wuerzburg.de> <9671A92C3C8B5744BC97F855F7CB646511B7AB37@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511B7AB37@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Joe and all, Jozef Babiarz wrote: > See my comments below demarked with [Joe] > > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: August 14, 2007 5:52 PM > To: Babiarz, Jozef (CAR:0S03) > Cc: philip.eardley@bt.com; pcn@ietf.org > Subject: Re: [PCN] PCN architecture new section on tunnelling > > Hi, > > Imagine a packet is tunneled from node A to some other node B, it is > decapsulated there and forwarded to destination C. Then, the traffic > takes the route from A over B to C. > 1st problem: how do we find the ingress node X of the packet at its PCN > egress Y? > > [Joe] One possible approach is to use a probe method something like. > PCN-ingress node using the IP header information of the flow to be > admitted generates and sends probe packets that can easily be detected > by the PCN-egress-node (in your case node C). The sent probe packets > contain as payload the address of the PCN-ingress-node so that the > PCN-egress-node knows where to send the pre-congestion information for > that flow. [end] > Usually, probes are simple packets. A probe from A is destined to B. Decapsulation at B does not work for the probe packet. If a tunnelled IP packet enters the PCN ingress A, then the probe needs to mimic this. I guess tunneling will be tricky with PCN. > 2nd problem: provided that we know the ingress node X, the path from A > over B to C does not necessarily coincide with normal IP routed path > from the corresponding PCN ingress X to egress Y. > > [Joe] It will coincide if the IP header information of the probe packet > is the same as media packet if admitted. By IP header information I > mean, source/destination IP address, source/destination port numbers, > protocol ID and DSCP value. The source/destination IP address, etc. is > that of endpoints and not boundary nodes that originate or consume probe > packets.[end] > Again, when tunneled IP packets enter the PCN domain, this poses additional challenges on probing as there are several stacked headers to be mimicked. Maybe there are other, simpler solutions. In any case: probing and marked flow termination guarantees that the admission and termination decision is associated with the right path which is not trivial with tunneling. Regards, Michael > If those packets are > admission marked, they may cause admission stop for traffic from X to Y > although they take a different path. > > Thus, the problem is that we associate the admission-stop-marking with > the path from the ingress to the egress of the packet. If the packet > took a different path than by typical IP routing, the interpretation of > the PCN information is leads to the wrong conclusions. Similar problems > occur with excess-traffic-marked packets if the corresponding PCN > information is associated with the path. The marked flow termination > (MFT) from the 3sm-draft associates the marking with the flow and can > cope well with arbitrarily routed flows. > > Possible solution: the marking from X to B needs to be evaluated at B > and be associated with the path from X to B, and the marking received > from B to Y needs to be evaluated at Y and be associated with the path > from B to Y. > [Joe] Not sure way the marking at B needs to be evaluated? At the > decapsulation point B, if the outer header's marking state is more > severe then it is copied onto the inner header. [end] > > I just want to say: tunneling with tunnel endpoints in PCN networks is > not yet understood. > > Best wishes, > > Michael > > Jozef Babiarz wrote: > >> Phil, please see my comment below demarked with [Joe]. >> >> /Regards, Joe/ >> email:babiarz@nortel.com >> Telephone:613-763-6098 >> >> >> > ------------------------------------------------------------------------ > >> *From:* philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> *Sent:* August 8, 2007 6:14 PM >> *To:* pcn@ietf.org >> *Subject:* [PCN] PCN architecture new section on tunnelling >> >> This is to flag up that I wrote a new sub-section (in Section 5, >> Detailed functional architecture) about tunelling: >> >> 5.8. Tunnelling >> >> It is possible that tunnels terminate at a PCN-node. It is important >> >> that any PCN-marking is preserved after decapsulation, so that it is >> >> still seen by the PCN-egress-node. To ensure this, on decapsulation >> >> the following rules are applied: >> >> o the PCN-marking state of the inner and outer headers are compared >> >> o if the inner header's marking state is more severe then it is >> >> preserved >> >> o if the outer header's marking state is more severe then it is >> >> copied onto the inner header >> >> o NB the order of increasing severity is: unmarked; PCN-marking with >> >> first encoding (ie associated with the PCN-lower-rate); PCN- >> >> marking with second encoding (ie associated with the PCN-upper- >> >> rate) >> >> Similarly, if encapsulation is done within the PCN-domain, then the >> >> following rule is applied: >> >> * any PCN-marking is copied into the outer header >> >> [Joe] The above may introduce unnecessary information leakage. Why not >> > > >> just at the encapsulation point mark all packets as unmarked. The >> decapsulation point can sort them out. Just realizes that excess rate >> marking approach will not work unless PCN-marking information is >> copied from inner to outer headers when encapsulating. [end] >> >> [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN >> nonce) is out of scope as we are not sure if it's need for PCN. If not >> > > >> than the "PCN nonce" would also need to be copied to outer header. >> > [end] > >> Tunnelling considerations also depend on which header bits the PCN WG >> >> decides to use. If the ECN bits are used then >> >> [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to >> >> its spirit. If the DSCP field is used then [RFC2983] needs to be >> >> considered carefully. >> >> An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to >> >> PCN-egress-nodes, in which case the rules above aren't needed. The >> >> potential reasons for doing such tunnelling are: the PCN-egress-node >> >> then automatically knows the address of the relevant PCN-ingress-node >> >> for a flow; even if ECMP is running, all PCN-packets on a particular >> >> ingress-egress-aggregate follow the same path. But it also has >> >> drawbacks: additional overhead in terms of bandwidth and processing; >> >> and the effective elimination of ECMP as a load balancing mechanism. >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 17 11:50:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM45d-0005Zv-Rs; Fri, 17 Aug 2007 11:50:21 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IM3Xy-0003go-Bn for pcn-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:15:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3Xx-0003gW-V3; Fri, 17 Aug 2007 11:15:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3Xx-0002Dw-8R; Fri, 17 Aug 2007 11:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B7AB1175B3; Fri, 17 Aug 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM3XS-0005iA-7k; Fri, 17 Aug 2007 11:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 17 Aug 2007 11:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Fri, 17 Aug 2007 11:50:21 -0400 Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-architecture-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-00.txt Pages : 32 Date : 2008-7-17 The purpose of this document is to describe a general architecture for flow admission and termination based on aggregated pre-congestion information in order to protect the quality of service of established inelastic flows within a single DiffServ domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pcn-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pcn-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-17105252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pcn-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pcn-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-17105252.I-D@ietf.org> --OtherAccess-- --NextPart 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://www1.ietf.org/mailman/listinfo/pcn --NextPart-- From pcn-bounces@ietf.org Fri Aug 17 12:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4Ta-0005Lq-1v; Fri, 17 Aug 2007 12:15:06 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IM4TY-0005LY-3v for pcn-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 12:15:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4TX-0005LQ-O9; Fri, 17 Aug 2007 12:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM4TX-0004j1-A7; Fri, 17 Aug 2007 12:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id CE6FC175BD; Fri, 17 Aug 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM4TW-00005S-4W; Fri, 17 Aug 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 17 Aug 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-architecture-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-00.txt Pages : 32 Date : 2008-8-17 The purpose of this document is to describe a general architecture for flow admission and termination based on aggregated pre-congestion information in order to protect the quality of service of established inelastic flows within a single DiffServ domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pcn-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pcn-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-17114102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pcn-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pcn-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-17114102.I-D@ietf.org> --OtherAccess-- --NextPart 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://www1.ietf.org/mailman/listinfo/pcn --NextPart-- From pcn-bounces@ietf.org Sat Aug 18 14:37:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMTBL-0000de-7O; Sat, 18 Aug 2007 14:37:55 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IMTBK-0000bR-Ff for pcn-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 14:37:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMTBK-0000aT-2C for pcn@ietf.org; Sat, 18 Aug 2007 14:37:54 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMTBJ-0003cQ-FL for pcn@ietf.org; Sat, 18 Aug 2007 14:37:53 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7IIbqAu014391; Sat, 18 Aug 2007 14:37:52 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7IIbl99002595; Sat, 18 Aug 2007 14:37:48 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Aug 2007 14:37:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture new section on tunnelling Date: Sat, 18 Aug 2007 14:37:46 -0400 Message-ID: In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511B2415D@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture new section on tunnelling Thread-Index: AcfaCXJksAu35/rvTceRV0cJc3CgAwEkoZpgAMp4jqA= References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3A7@E03MVZ1-UKDY.domain1.systemhost.net> <9671A92C3C8B5744BC97F855F7CB646511B2415D@zcarhxm1.corp.nortel.com> To: , X-OriginalArrivalTime: 18 Aug 2007 18:37:47.0710 (UTC) FILETIME=[DFC125E0:01C7E1C6] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, HTML_70_90 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 6f7d7d4126a03a70c87b926ff3be4cd9 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1225345639==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1225345639== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E1C6.DF4A2694" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E1C6.DF4A2694 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Joe, =20 * any PCN-marking is copied into the outer header [Joe] The above may introduce unnecessary information leakage. Why not just at the encapsulation point mark all packets as unmarked. The decapsulation point can sort them out. Just realizes that excess rate marking approach will not work unless PCN-marking information is copied from inner to outer headers when encapsulating. [end] =20 [DLB] The copying can simplify dealing with the various headers. If the PCN marking is always in the outermost header (copied out on ingress, copied in on egress), then dealing with PCN marking is orthogonal to tunnel encap/ decap, and in particular, the right thing happens if a tunnel crosses a PCN boundary and has its egress in the middle of a PCN domain. This is related to RFC 2983's uniform model for dealing with diffserv and tunnels, and some of the tunnel discussion in RFC 3270 (MPLS and diffserv) may also be useful to review (not because MPLS and PCN ought to be in scope, but rather because Francois and the RFC 3270 co-authors did a fine job of exploring the implications of the uniform and pipe models in RFC 3270 to the next levels of detail. =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 ________________________________ From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Tuesday, August 14, 2007 2:17 PM To: philip.eardley@bt.com; pcn@ietf.org Subject: RE: [PCN] PCN architecture new section on tunnelling =09 =09 Phil, please see my comment below demarked with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:14 PM To: pcn@ietf.org Subject: [PCN] PCN architecture new section on tunnelling =20 This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about tunelling: =20 5.8. Tunnelling =20 It is possible that tunnels terminate at a PCN-node. It is important that any PCN-marking is preserved after decapsulation, so that it is still seen by the PCN-egress-node. To ensure this, on decapsulation the following rules are applied: =20 o the PCN-marking state of the inner and outer headers are compared =20 o if the inner header's marking state is more severe then it is preserved =20 o if the outer header's marking state is more severe then it is copied onto the inner header =20 o NB the order of increasing severity is: unmarked; PCN-marking with first encoding (ie associated with the PCN-lower-rate); PCN- marking with second encoding (ie associated with the PCN-upper- rate) =20 Similarly, if encapsulation is done within the PCN-domain, then the following rule is applied: =20 * any PCN-marking is copied into the outer header [Joe] The above may introduce unnecessary information leakage. Why not just at the encapsulation point mark all packets as unmarked. The decapsulation point can sort them out. Just realizes that excess rate marking approach will not work unless PCN-marking information is copied from inner to outer headers when encapsulating. [end] =20 [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN nonce) is out of scope as we are not sure if it's need for PCN. If not than the "PCN nonce" would also need to be copied to outer header. [end]=20 =20 Tunnelling considerations also depend on which header bits the PCN WG decides to use. If the ECN bits are used then [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to its spirit. If the DSCP field is used then [RFC2983] needs to be considered carefully. =20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes, in which case the rules above aren't needed. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow; even if ECMP is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path. But it also has drawbacks: additional overhead in terms of bandwidth and processing; and the effective elimination of ECMP as a load balancing mechanism. =20 =20 ------_=_NextPart_001_01C7E1C6.DF4A2694 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Joe,
 

·        =20 any PCN-marking is = copied=20 into the outer header

[Joe] The above may introduce = unnecessary=20 information leakage. Why not just at the encapsulation point mark all = packets as=20 unmarked. The decapsulation point can sort them out. Just realizes that = excess=20 rate marking approach will not work unless PCN-marking information is = copied=20 from inner to outer headers when encapsulating. [end]

 

[DLB] The copying can = simplify dealing=20 with the various headers.  If the

PCN marking is always in the outermost header (copied = out on=20 ingress, copied

in on egress), then dealing with PCN marking is = orthogonal to=20 tunnel encap/

decap, and in particular, the right thing happens if a tunnel = crosses a=20 PCN

boundary and has its egress in the middle of a PCN domain.  = This is=20 related

to RFC 2983's uniform model for dealing with diffserv and tunnels, and = some

of the tunnel discussion in RFC 3270 (MPLS and diffserv) = may also be=20 useful

to review (not because MPLS and PCN ought to be in scope, = but rather=20 because

Francois and the RFC 3270 co-authors did a fine = job of=20 exploring the

implications of the uniform and pipe models in RFC 3270 to the next=20 levels

of detail.

 

Thanks,

--David

----------------------------------------------------=20
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748=20
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------=20


From: Jozef Babiarz=20 [mailto:babiarz@nortel.com]
Sent: Tuesday, August 14, 2007 = 2:17=20 PM
To: philip.eardley@bt.com; = pcn@ietf.org
Subject: RE:=20 [PCN] PCN architecture new section on tunnelling

Phil, = please see my=20 comment below demarked with [Joe].

 

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

From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:14 = PM
To: pcn@ietf.org
Subject: [PCN] PCN architecture = new=20 section on tunnelling

 

This is to flag up that I wrote = a new=20 sub-section (in Section 5, Detailed functional architecture) about=20 tunelling:

 

5.8.  = Tunnelling

 

   It is possible that tunnels = terminate at=20 a PCN-node.  It is important

   that any PCN-marking is = preserved after=20 decapsulation, so that it is

   still seen by the = PCN-egress-node. =20 To ensure this, on decapsulation

   the following rules are=20 applied:

 

   o  the PCN-marking state = of the=20 inner and outer headers are compared

 

   o  if the inner header's = marking=20 state is more severe then it is

     =20 preserved

 

   o  if the outer header's = marking=20 state is more severe then it is

      copied onto = the inner=20 header

 

   o  NB the order of = increasing=20 severity is: unmarked; PCN-marking with

      first = encoding (ie=20 associated with the PCN-lower-rate); PCN-

      marking with = second=20 encoding (ie associated with the = PCN-upper-

     =20 rate)

 

   Similarly, if encapsulation is = done=20 within the PCN-domain, then the

   following rule is=20 applied:

 

·        =20 any = PCN-marking=20 is copied into the outer header

[Joe] The above = may introduce=20 unnecessary information leakage. Why not just at the encapsulation = point mark=20 all packets as unmarked. The decapsulation point can sort them out. = Just=20 realizes that excess rate marking approach will not work unless = PCN-marking=20 information is copied from inner to outer headers when encapsulating.=20 [end]

 

[Joe] I’m = assuming for time=20 being that “PCN nonce” (similar to ECN nonce) is out of = scope as we are not=20 sure if it’s need for PCN. If not than the “PCN = nonce” would also need to be=20 copied to outer header. [end]

 

   Tunnelling considerations also = depend on=20 which header bits the PCN WG

   decides to use.  If the = ECN bits are=20 used then

   [I-D.briscoe-tsvwg-ecn-tunnel] = applies;=20 the rules above conform to

   its spirit.  If the DSCP = field is=20 used then [RFC2983] needs to be

   considered=20 carefully.

 

   An operator may wish to tunnel=20 PCN-traffic from PCN-ingress-nodes to

   PCN-egress-nodes, in which case = the rules=20 above aren't needed.  The

   potential reasons for doing = such=20 tunnelling are: the PCN-egress-node

   then automatically knows the = address of=20 the relevant PCN-ingress-node

   for a flow; even if ECMP is = running, all=20 PCN-packets on a particular

   ingress-egress-aggregate follow = the same=20 path.  But it also has

   drawbacks: additional overhead = in terms=20 of bandwidth and processing;

   and the effective elimination = of ECMP as=20 a load balancing mechanism.

 

 

------_=_NextPart_001_01C7E1C6.DF4A2694-- --===============1225345639== 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://www1.ietf.org/mailman/listinfo/pcn --===============1225345639==-- From pcn-bounces@ietf.org Mon Aug 20 03:37:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1pT-0000ML-6a; Mon, 20 Aug 2007 03:37:39 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IN1pR-0000ME-Ez for pcn-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:37:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1pN-0000Lw-JY for pcn@ietf.org; Mon, 20 Aug 2007 03:37:33 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN1pM-0007pS-H6 for pcn@ietf.org; Mon, 20 Aug 2007 03:37:33 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 08:37:31 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, new addressing sub-section Date: Mon, 20 Aug 2007 08:37:30 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3FE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511B7A93E@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, new addressing sub-section Thread-Index: Acfdc7r2ri2gV9RnQA+fOrJNSfkvNQB9AimwAOUsqKA= From: To: , , X-OriginalArrivalTime: 20 Aug 2007 07:37:31.0553 (UTC) FILETIME=[F782D110:01C7E2FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7742ab7d8f94ae8c6013d3682e631edb Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0047698444==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0047698444== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E2FC.F71FC400" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E2FC.F71FC400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe,=20 Will add something about probing to the addressing section. =20 Tina, not entirely sure what you mean about merging. There is some text near the start of section 4 that may be useful? =20 PCN-ingress-nodes are flow-aware (required for policing purposes). In several deployment scenarios PCN-egress-nodes will also be flow aware. (Normally this adds no complexity since a PCN-boundary- node acts as both a PCN-ingress-node and as a PCN-egress-node.) =20 phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 15 August 2007 19:26 To: Tina TSOU; pcn@ietf.org; Eardley,PL,Philip,CXR9 R Subject: RE: [PCN] PCN architecture, new addressing sub-section =20 See additional comments demarked with [Joe1] below. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: August 13, 2007 2:32 AM To: pcn@ietf.org; philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03) Subject: Re: [PCN] PCN architecture, new addressing sub-section =20 =20 ----- Original Message -----=20 From: Jozef Babiarz =20 To: philip.eardley@bt.com ; pcn@ietf.org=20 Sent: Saturday, August 11, 2007 4:52 AM Subject: RE: [PCN] PCN architecture, new addressing sub-section =20 See my comments below demarked with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, new addressing sub-section =20 This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about addressing: =20 5.7. Addressing =20 PCN-nodes may need to know the address of other PCN-nodes: =20 o in all cases PCN-interior-nodes don't need to know the address of any other PCN-nodes, except their next hop neighbours =20 o in the cases of admission or termination decision by a PCN- boundary-node, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, at a minimum so that the PCN-ingress-node can be informed to enforce the admission decision through policing. The addressing information can be gathered from signalling, for example as described for RSVP in [I-D.lefaucheur-rsvp-ecn]. Alternatively, if PCN-traffic is always tunnelled across the PCN-domain, then the PCN-ingress- node's address is simply the source address of the outer packet header. [Joe] I believe that the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified "... enforce the admission and flow termination decision through policing." [end] [Tina: sounds excellent.] =20 [Joe] Would also like to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. "Another method that may be used to discover and exchange address information between PCN-boundary-nodes is through probing. The PCN-ingerss-node using the IP header information of the flow to be admitted generates and sends probe packets that can easily be detected by the PCN-egress-node. The sent probe packets contain as payload the address of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow." [end] [Tina: I found there is similarity between this probe method and RSVP method. The PCN ingress node places its address in the probe packet or RSVP PATH message, the interior nodes doesn't care about these packets, the PCN egress node could associate the flow with the correct PCN ingress node after extracting the address of the PCN ingress node embedded in the probe packet or RSVP PATH message. These kinds of methods have a disadvantage: it's hard for the egress node to merge the flows. A PCN egress node may create a mapping table like follows: [Joe1] I do not see a need to merge flows in egress node for admission control if probing is used. Also, no need to build and maintain ingress-egress flow aggregating tables or perform rate measurements of marked or unmarked PCN traffic if the marking as in 3sm draft is used. [end] =09 FLOW FLOW's Ingress node flow1 Ingress A flow2 Ingress A flow3 Ingress B flow4 Ingress B If there are too many flows, the table may be very large. One option to solve addressing of PCN-boundary node may be to use symmetric route. For example, supposing IBGP is running on the PCN-boundary node: 1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress B----2.2.2.0/24 IBGP could tell the egress node B that it has to go through PCN ingress A to reach 1.1.1.0/24, the egress node B could then regard a packet from 1.1.1.0/24 will come through ingress A, given a symmetric route scenario. The disadvantage of this option may be the requirement of symmetric route. The advantage of this option is that merged table item may be supported. Network Network's Ingress node 1.1.1.0/24 Ingress A]=20 =20 o in the cases of admission or termination decision by a central control node, the PCN-egress-node needs to be configured with the address of the centralised node. In addition, depending on the exact deployment scenario and its signalling, the centralised node may need to know the addresses of the PCN-ingress-node and PCN- egress-node, and the PCN-egress-node know the address of the PCN- ingress-node. NOTE: Consideration of the centralised case is out of scope of the initial PCN WG Charter. =20 [Joe] I think we need a bit more discussion about the central control node. I'm thinking of something like a PDP where pre-congestion information is sent to and after verifying the policy the result is sent to PCN-ingress-node to care out the action. For this scenario, the PCN-boundary-nodes need to be provisioned with the address of the central policy control node. [end] =20 [Joe] Can the proponents of the central control node expand a bit more on how this will work? [end] [Tina: A centralized node will not burden the addressing of PCN-boundary nodes. To make metering, the egress node always has to know the ingress node address a flow associated. A centralized node makes the egress node doesn't need to notify the pre-congestion information (CLE) to the ingress node, instead, the egress node will send it to the centralized node. So the address of the centralized node has to be provisioned on the egress node. When the egress node notifies the CLE to the centralized node, it has to send the ingress node address associated the CLE. So the centralized would know the address of every PCN boundary node.] =20 (I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder if the description of the centralised node case is too long, as the case is strictly out of scope.) =20 =20 =09 ________________________________ _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C7E2FC.F71FC400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joe,

Will add something about probing to = the addressing section.

 

Tina, not entirely sure what you = mean about merging. There is some text near the start of section 4 that may = be useful?

 

PCN-ingress-nodes are flow-aware = (required for policing purposes).  In

      = several deployment scenarios PCN-egress-nodes will also be = flow

      = aware.  (Normally this adds no complexity since a = PCN-boundary-

      node = acts as both a PCN-ingress-node and as a PCN-egress-node.)

 

phil

 

-----Original Message-----
From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: 15 August 2007 = 19:26
To: Tina TSOU; = pcn@ietf.org; Eardley,PL,Philip,CXR9 R
Subject: RE: [PCN] PCN architecture, new addressing sub-section

 

See additional = comments demarked with [Joe1] below.

 

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

From: Tina TSOU [mailto:tena@huawei.com]
Sent: August 13, 2007 = 2:32 AM
To: pcn@ietf.org; philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03)
Subject: Re: [PCN] PCN architecture, new addressing sub-section

 

 

----- Original Message ----- =

Sent: Saturday, August 11, 2007 4:52 AM

Subject: RE: [PCN] PCN architecture, new addressing sub-section

 

See my comments = below demarked with [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, new addressing sub-section

 

This is to flag up that I wrote a new = sub-section (in Section 5, Detailed functional architecture) about = addressing:

 

5.7.  Addressing

 

   PCN-nodes may need to know the address of other = PCN-nodes:

 

   o  in all cases PCN-interior-nodes don't need = to know the address of

      any other PCN-nodes, except their = next hop neighbours

 

   o  in the cases of admission or termination = decision by a PCN-

      boundary-node, the = PCN-egress-node needs to know the address of

      the PCN-ingress-node associated = with a flow, at a minimum so that

      the PCN-ingress-node can be = informed to enforce the admission

      decision through policing.  = The addressing information can be

      gathered from signalling, for = example as described for RSVP in

      [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic is

      always tunnelled across the = PCN-domain, then the PCN-ingress-

      node's address is simply the = source address of the outer packet

      header.

[Joe] I believe that the = PCN-ingress-node should enforce both the admission and flow termination decisions. So = would suggest that the above text be modified “... enforce the admission = and flow termination decision through policing.” = [end]

[Tina: sounds excellent.]

 

[Joe] Would also like to add that = probing can be used to discover and exchange address information of = PCN-boundary-nodes. “Another method that may be used to discover and exchange address information between PCN-boundary-nodes is through probing. The = PCN-ingerss-node using the IP header information of the flow to be admitted generates and = sends probe packets that can easily be detected by the PCN-egress-node. The = sent probe packets contain as payload the address of the PCN-ingress-node so = that the PCN-egress-node knows where to send the pre-congestion information = for that flow.” [end]

[Tina: I found = there is similarity between this probe method and RSVP method. The PCN ingress = node places its address in the probe packet or RSVP PATH message, the = interior nodes doesn't care about these packets, the PCN egress node could associate = the flow with the correct PCN ingress node after extracting the address of the = PCN ingress node embedded in the probe packet or RSVP PATH message.
These kinds of methods have a disadvantage: it's hard for the egress = node to merge the flows. A PCN egress node may create a mapping table like = follows:

[Joe1] I do not = see a need to merge flows in egress node for admission control if probing is = used. Also, no need to build and maintain ingress-egress flow aggregating = tables or perform rate measurements of marked or unmarked PCN traffic if the = marking as in 3sm draft is used. [end]


FLOW    FLOW's Ingress node
flow1    Ingress A
flow2    Ingress A
flow3    Ingress B
flow4    Ingress B
If there are too many flows, the table may be very large.
One option to solve addressing of PCN-boundary node may be to use = symmetric route. For example, supposing IBGP is running on the PCN-boundary = node:
1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress = B----2.2.2.0/24
IBGP could tell the egress node B that it has to go through PCN ingress = A to reach 1.1.1.0/24, the egress node B could then regard a packet from = 1.1.1.0/24 will come through ingress A, given a symmetric route scenario.
The disadvantage of this option may be the requirement of symmetric = route. The advantage of this option is that merged table item may be supported.
Network   Network's Ingress node
1.1.1.0/24   Ingress A] 

 

   o  in the cases of admission or termination = decision by a central

      control node, the PCN-egress-node = needs to be configured with the

      address of the centralised = node.  In addition, depending on the

      exact deployment scenario and its signalling, the centralised node

      may need to know the addresses of = the PCN-ingress-node and PCN-

      egress-node, and the = PCN-egress-node know the address of the PCN-

      ingress-node.  NOTE: = Consideration of the centralised case is out

      of scope of the initial PCN WG = Charter.

 

[Joe] I think we need a bit more = discussion about the central control node. I’m thinking of something like a = PDP where pre-congestion information is sent to and after verifying the = policy the result is sent to PCN-ingress-node to care out the action. For this = scenario, the PCN-boundary-nodes need to be provisioned with the address of the = central policy control node. [end]

 

[Joe] Can the proponents = of the central control node expand a bit more on how this will work? = [end]

[Tina: A centralized node will not burden the addressing of PCN-boundary nodes. = To make metering, the egress node always has to know the ingress node = address a flow associated. A centralized node makes the egress node doesn’t = need to notify the pre-congestion information (CLE) to the ingress node, = instead, the egress node will send it to the centralized node. So the address of the centralized node has to be provisioned on the egress node. When the = egress node notifies the CLE to the centralized node, it has to send the ingress = node address associated the CLE. So the centralized would know the address of = every PCN boundary node.]

 

(I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about = different ways the egress could know the ingress address. Also, I wonder if the = description of the centralised node case is too long, as the case is strictly out of = scope.)

 

 

______________________________________________= _
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn

=00 ------_=_NextPart_001_01C7E2FC.F71FC400-- --===============0047698444== 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://www1.ietf.org/mailman/listinfo/pcn --===============0047698444==-- From pcn-bounces@ietf.org Mon Aug 20 03:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1vU-00065E-CV; Mon, 20 Aug 2007 03:43:52 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IN1vT-00064m-A5 for pcn-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:43:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1vT-00064d-0a for pcn@ietf.org; Mon, 20 Aug 2007 03:43:51 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN1vR-00051s-Hr for pcn@ietf.org; Mon, 20 Aug 2007 03:43:50 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 08:43:48 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Date: Mon, 20 Aug 2007 08:43:48 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3FF@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Thread-Index: Acfbddn1+729EbU3QK2pzdS3ovm5aAHh1zhw From: To: X-OriginalArrivalTime: 20 Aug 2007 07:43:48.0969 (UTC) FILETIME=[D877ED90:01C7E2FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R > Sent: 10 August 2007 18:43 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking >=20 > Phil, >=20 > At 23:08 08/08/2007, philip.eardley@bt.com wrote: > > > The unintended implication that all packets are either marked or not > > > marked > > > should also be carefully avoided. The draft needs to say explicitly > >that > > > "Admission (or Termination) marking will be an encoding of some > > > combination > > > of codepoints in the IP header to signal a varying fractional number > >from > > > a > > > path of PCN-interior-nodes to a PCN-egress-node" > > > >I'm not sure this is accurate for either of the main categories of > >marking algorithm (threshold marking [=3Dstep marking of cl-architecture], > >or excess-rate-marking [where a mark means so many bits in excess]). (it > >is true for ramp-marking of cl-architecture.) >=20 > 1/ threshold marking >=20 > As load builds, assuming traffic isn't pure CBR, a queue will very likley > be oscillating up and down quite fast. Here's a picture at packet > granularity that I did about a year ago to illustrate this: > es/dmbac_queue.pdf> >=20 > Even if you have a step marking threshold at some queue length (any > positive horizontal line across the top graph), only a proportion of > packet > will be marked. >=20 > I believe Anna's simulations of step vs ramp demonstrated they weren't > that > different, which is what I would expect. A ramp merely ensures there is a > smooth transition from zero marking to full marking even if the traffic > doesn't provide any randomness itself (pure CBR) or its variable but > highly > smoothed by statistical aggregation. [phil] yes, agree. This is just interpretation of the phrase "signal a varying fractional number" >=20 > 2/ Excess rate marking >=20 > Surely the whole point here is to mark a proportion of packets to signify > the amount of excess rate. So I don't quite understand how it will either > be 0% or 100% marking? Am I missing something? >=20 >=20 > Bob >=20 >=20 >=20 > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 20 03:44:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1wX-0006Su-Pl; Mon, 20 Aug 2007 03:44:57 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IN1wW-0006Sp-9F for pcn-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1wV-0006Sg-W2 for pcn@ietf.org; Mon, 20 Aug 2007 03:44:55 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN1wU-00054F-H6 for pcn@ietf.org; Mon, 20 Aug 2007 03:44:55 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 08:44:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-eardley-pcn-architecture-00 function v topology Date: Mon, 20 Aug 2007 08:44:53 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC400@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <5.2.1.1.2.20070810184610.03149b70@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-architecture-00 function v topology Thread-Index: Acfbd/+QKsIBYmHWTkekwFvbmwfI4QHhe6Tw From: To: X-OriginalArrivalTime: 20 Aug 2007 07:44:53.0968 (UTC) FILETIME=[FF35FD00:01C7E2FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Bob, thanks will add clarification on lines you suggest phil > -----Original Message----- > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R > Sent: 10 August 2007 18:58 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-eardley-pcn-architecture-00 function v topology >=20 > Phil, >=20 > I should have said in the last mail that I'm picking off individual > responses as new threads as I get time... >=20 > At 23:08 08/08/2007, philip.eardley@bt.com wrote: > > > * Functional or topological? > > > Is it intentional that the high level functions are classified by > >which > > > type of node does them in 3 cases and what function is to be done in > >the > > > others? Would it be possible to define functions in the abstract > >first, > > > then say which functions have to be implemented on certain types of > >nodes? > > > Or does this just make it unnecessarily incomprehensible? > > > >[think your comment applies to S5, Detailed functional architecture] > >it was intentional. I found it the easiest way to describe it! >=20 > Yup sorry, I meant S5. Here's the contents: >=20 > 5. Detailed Functional architecture . . . . . . . . . . . . . . . 12 > 5.1. PCN-interior-node functions . . . . . . . . . . . . . . . 12 > 5.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 13 > 5.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 13 > 5.4. Admission control functions . . . . . . . . . . . . . . . 14 > 5.5. Probing functions . . . . . . . . . . . . . . . . . . . . 14 > 5.6. Flow termination functions . . . . . . . . . . . . . . . . 15 >=20 > It might just be worth saying it isn't actually just a purely functional > architecture even tho the title says it is (or some such excuse). >=20 > What's actually happening here is that the information and control > necessary for a particular function naturally come together at a > particular > place in the directed topology of the domain. But many protocols are > designed to carry information from the natural place of control to another > place that wants to control the system. >=20 > In the data plane, traffic flows in one direction, so the natural places > are not easy to change. But in the signalling plane, you get all these > wars > over where control should be (sender, receiver, PDP, etc), which is what > signalling protocols are meant to do - allow control to be moved around. >=20 > In summary, these issues should be brought out explicitly in an arch doc, > so something needs to be said about this rather than leaving it implicit. >=20 > Bob >=20 >=20 > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 20 03:54:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN262-0004lz-7r; Mon, 20 Aug 2007 03:54:46 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IN261-0004lu-Hh for pcn-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:54:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN261-0004la-60 for pcn@ietf.org; Mon, 20 Aug 2007 03:54:45 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN260-0008EB-BZ for pcn@ietf.org; Mon, 20 Aug 2007 03:54:44 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 08:54:43 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture - revised text on ECMP Date: Mon, 20 Aug 2007 08:54:42 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC401@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511B244B9@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture - revised text on ECMP Thread-Index: AcfaCU+NgYL9vlL2RBe24G2bEVtecAElm41gARejYvA= From: To: , X-OriginalArrivalTime: 20 Aug 2007 07:54:43.0642 (UTC) FILETIME=[5EAF19A0:01C7E2FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0291533350==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0291533350== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E2FF.5E3D5CE0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E2FF.5E3D5CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-line phil =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 14 August 2007 21:58 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN architecture - revised text on ECMP =20 Please see my comment below denoted with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:13 PM To: pcn@ietf.org Subject: [PCN] PCN architecture - revised text on ECMP =20 This is to flag up that I wrote some revised text on ECMP (in Section 6, Design goals and challenges): =20 The following are open issues. They are taken from [I-D.briscoe-tsvwg-cl-architecture] which also describes some possible solutions (potential solutions are out of scope for this document). Note that some may be considered unimportant in general or in specific deployment scenarios. =20 =20 o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion is measured on a specific ingress-egress-aggregate. However, if the PCN-domain runs ECMP, then traffic on this ingress-egress- aggregate may follow several different paths - some of the paths could be pre-congested whilst others are not. There are two potential problems: [Joe] Actual there are 3 or 4 potential problems. [end] =20 1. over-admission: a new flow is admitted (because the pre- congestion level measured by the PCN-egress-node is sufficiently diluted by unmarked packets from non-congested paths that a new flow is admitted), but its packets travel through a pre-congested PCN-node [Joe] 2. under-admission: a new flow is blocked (because the pre-congestion level measured by the PCN-egress-node is sufficiently diluted by marked packets from pre-congested PCN-nodes that a new flow is blocked admission), but its packets would travel through a un-congested path. [end] =20 [phil] ok, will add. =20 2. ineffective termination: flows are terminated, however their path doesn't travel through the (pre-)congested router(s). [Joe] The above requires that we only terminate marked flows. In the "Flow termination" section of the architecture draft there is no mention that only flows travelling through congested router(s) are to be terminated. I believe we need to add statement that only flows as indicated by packet(s) marking indicating passing over link(s) where the PCN-upper-rate was exceeded as requirement for ECMP. For flow termination to work with ECMP, only flows that pass over link(s) where PCN-upper-rate was exceeded should be terminated. =20 [phil] the start of this section of open issues says "potential solutions are out of scope for this document". However, I think it would be worth explicitly adding in a statement that says the characteristic that a solution would have (which is essentially the opposite of the problem statements) =20 The overall PCN solution for flow termination must solve the second problem, since flow termination is a 'last resort'. For flow admission, the risk of slight over-admission may be acceptable (particularly with flow termination as a fall-back), at least for some operators. [Joe] I believe we should state that flow termination provides protection to the network should over-admission occur. However, over-admission followed by termination of some over-admitted flows is not desirable as it leads to dissatisfied users.=20 =20 [phil[ will add something about the risk of dissatisfied users =20 ------_=_NextPart_001_01C7E2FF.5E3D5CE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In-line

phil

 

-----Original Message-----
From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: 14 August 2007 21:58
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] PCN architecture - revised text on ECMP

 

Please see my = comment below denoted with [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:13 PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture - revised text on ECMP

 

This is to flag up that I wrote some revised = text on ECMP (in Section 6, Design goals and challenges):

 

   The following are open issues.  They are taken = from

   [I-D.briscoe-tsvwg-cl-architecture] which also = describes some

   possible solutions (potential solutions are out of = scope for this

   document).  Note that some may be considered unimportant in general

   or in specific deployment = scenarios.

 

=  

   o  ECMP (Equal Cost Multi-Path) Routing: The = level of pre-congestion

      is measured on a specific ingress-egress-aggregate.  However, if

      the PCN-domain runs ECMP, then = traffic on this ingress-egress-

      aggregate may follow several = different paths - some of the paths

      could be pre-congested whilst = others are not.  There are two

      potential = problems:

[Joe] Actual = there are 3 or 4 potential problems. [end]

 

      1.  over-admission: a new = flow is admitted (because the pre-

          = congestion level measured by the PCN-egress-node is

          = sufficiently diluted by unmarked packets from non-congested

          paths = that a new flow is admitted), but its packets travel

          through a pre-congested PCN-node

[Joe] 2.  = under-admission: a new flow is blocked (because the pre-congestion level measured by the PCN-egress-node is sufficiently diluted by marked packets from = pre-congested PCN-nodes that a new flow is blocked admission), but its packets would = travel through a un-congested path. [end]

 

[phil] ok, will = add.

 

      2.  ineffective termination: = flows are terminated, however their

          path = doesn't travel through the (pre-)congested router(s).

[Joe] The above = requires that we only terminate marked flows. In the “Flow = termination” section of the architecture draft there is no mention that only flows travelling through congested router(s) are to be terminated. I believe we need to = add statement that only flows as indicated by packet(s) marking indicating = passing over link(s) where the PCN-upper-rate was exceeded as requirement for = ECMP. For flow termination to work with ECMP, only flows that pass over link(s) = where PCN-upper-rate was exceeded should be terminated.

 

[phil] the start = of this section of open issues says “potential solutions are = out of scope for this document”. However, I think it would be worth = explicitly adding in a statement that says the characteristic that a solution would have = (which is essentially the opposite of the problem statements)

 

      The overall PCN solution for flow termination must solve the

      second problem, since flow = termination is a 'last resort'.  For

      flow admission, the risk of = slight over-admission may be

      acceptable (particularly with = flow termination as a fall-back), at

      least for some = operators.

[Joe] I believe = we should state that flow termination provides protection to the network should over-admission occur. However, over-admission followed by termination of = some over-admitted flows is not desirable as it leads to dissatisfied users. =

=  

[phil[ will add something about the = risk of dissatisfied users

 

=00 ------_=_NextPart_001_01C7E2FF.5E3D5CE0-- --===============0291533350== 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://www1.ietf.org/mailman/listinfo/pcn --===============0291533350==-- From pcn-bounces@ietf.org Mon Aug 20 04:45:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2tK-0006qO-QT; Mon, 20 Aug 2007 04:45:42 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IN2tJ-0006qJ-Rl for pcn-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 04:45:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2tJ-0006qB-GO for pcn@ietf.org; Mon, 20 Aug 2007 04:45:41 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN2tI-00011Q-J9 for pcn@ietf.org; Mon, 20 Aug 2007 04:45:41 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 09:45:39 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture new section on tunnelling Date: Mon, 20 Aug 2007 09:45:38 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC403@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <46C223F2.3000100@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture new section on tunnelling Thread-Index: AcfevdVkvekXSAdHR5aLqYZsjoBFagERiMyw From: To: , X-OriginalArrivalTime: 20 Aug 2007 08:45:39.0155 (UTC) FILETIME=[7BE96230:01C7E306] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael Good points. To me your tunnelling analysis is another example of multi-path; like ECMP it's quite tricky for PCN.=20 for flow termination, this can be solved by terminating flows that are actually marked (3sm-draft is one example, the Briscoe-cl-architecture gave another).=20 For adm ctrl, the solutions seem to be:=20 - tunnel all traffic between PCN-ingress-node and PCN-egress-node (I think this works for your tunnelling examples as well as for ECMP) - accept the adm decision is approximate;=20 - do probing for each flow admission in terms of knowing what the PCN-ingress-node is (so that you know where to do policing to enforce the adm decision), wouldn't this still be done at the signalling level? I suppose the question is then what happens if eg rsvp is tunnelled? phil > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 14 August 2007 22:52 > To: Jozef Babiarz > Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] PCN architecture new section on tunnelling >=20 > Hi, >=20 > Imagine a packet is tunneled from node A to some other node B, it is > decapsulated there and forwarded to destination C. Then, the traffic > takes the route from A over B to C. > 1st problem: how do we find the ingress node X of the packet at its PCN > egress Y? > 2nd problem: provided that we know the ingress node X, the path from A > over B to C does not necessarily coincide with normal IP routed path > from the corresponding PCN ingress X to egress Y. If those packets are > admission marked, they may cause admission stop for traffic from X to Y > although they take a different path. >=20 > Thus, the problem is that we associate the admission-stop-marking with > the path from the ingress to the egress of the packet. If the packet > took a different path than by typical IP routing, the interpretation of > the PCN information is leads to the wrong conclusions. Similar problems > occur with excess-traffic-marked packets if the corresponding PCN > information is associated with the path. The marked flow termination > (MFT) from the 3sm-draft associates the marking with the flow and can > cope well with arbitrarily routed flows. >=20 > Possible solution: the marking from X to B needs to be evaluated at B > and be associated with the path from X to B, and the marking received > from B to Y needs to be evaluated at Y and be associated with the path > from B to Y. >=20 > I just want to say: tunneling with tunnel endpoints in PCN networks is > not yet understood. >=20 > Best wishes, >=20 > Michael >=20 > Jozef Babiarz wrote: > > > > Phil, please see my comment below demarked with [Joe]. > > > > /Regards, Joe/ > > email:babiarz@nortel.com > > Telephone:613-763-6098 > > > > ------------------------------------------------------------------------ > > > > *From:* philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > *Sent:* August 8, 2007 6:14 PM > > *To:* pcn@ietf.org > > *Subject:* [PCN] PCN architecture new section on tunnelling > > > > This is to flag up that I wrote a new sub-section (in Section 5, > > Detailed functional architecture) about tunelling: > > > > 5.8. Tunnelling > > > > It is possible that tunnels terminate at a PCN-node. It is important > > > > that any PCN-marking is preserved after decapsulation, so that it is > > > > still seen by the PCN-egress-node. To ensure this, on decapsulation > > > > the following rules are applied: > > > > o the PCN-marking state of the inner and outer headers are compared > > > > o if the inner header's marking state is more severe then it is > > > > preserved > > > > o if the outer header's marking state is more severe then it is > > > > copied onto the inner header > > > > o NB the order of increasing severity is: unmarked; PCN-marking with > > > > first encoding (ie associated with the PCN-lower-rate); PCN- > > > > marking with second encoding (ie associated with the PCN-upper- > > > > rate) > > > > Similarly, if encapsulation is done within the PCN-domain, then the > > > > following rule is applied: > > > > * any PCN-marking is copied into the outer header > > > > [Joe] The above may introduce unnecessary information leakage. Why not > > just at the encapsulation point mark all packets as unmarked. The > > decapsulation point can sort them out. Just realizes that excess rate > > marking approach will not work unless PCN-marking information is > > copied from inner to outer headers when encapsulating. [end] > > > > [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN > > nonce) is out of scope as we are not sure if it's need for PCN. If not > > than the "PCN nonce" would also need to be copied to outer header. [end] > > > > Tunnelling considerations also depend on which header bits the PCN WG > > > > decides to use. If the ECN bits are used then > > > > [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to > > > > its spirit. If the DSCP field is used then [RFC2983] needs to be > > > > considered carefully. > > > > An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to > > > > PCN-egress-nodes, in which case the rules above aren't needed. The > > > > potential reasons for doing such tunnelling are: the PCN-egress-node > > > > then automatically knows the address of the relevant PCN-ingress-node > > > > for a flow; even if ECMP is running, all PCN-packets on a particular > > > > ingress-egress-aggregate follow the same path. But it also has > > > > drawbacks: additional overhead in terms of bandwidth and processing; > > > > and the effective elimination of ECMP as a load balancing mechanism. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > >=20 > -- > 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://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 20 07:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN5Iy-0002sU-9w; Mon, 20 Aug 2007 07:20:20 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IN5Iw-0002sH-CQ for pcn-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 07:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN5Iw-0002s8-2o for pcn@ietf.org; Mon, 20 Aug 2007 07:20:18 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN5Iu-0000oB-G0 for pcn@ietf.org; Mon, 20 Aug 2007 07:20:18 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 12:20:15 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 12:20:15 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1187608814539; Mon, 20 Aug 2007 12:20:14 +0100 Received: from mut.jungle.bt.co.uk ([10.86.16.151]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7KBK9O8018543; Mon, 20 Aug 2007 12:20:12 +0100 Message-Id: <5.2.1.1.2.20070820115053.03b83150@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 20 Aug 2007 12:20:10 +0100 To: menth@informatik.uni-wuerzburg.de From: Bob Briscoe Subject: Re: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking In-Reply-To: <46BD5E0D.6050803@informatik.uni-wuerzburg.de> References: <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 20 Aug 2007 11:20:15.0641 (UTC) FILETIME=[1520D090:01C7E31C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael, At 07:58 11/08/2007, Michael Menth wrote: >Hi Bob, > >Bob Briscoe wrote: >>Phil, >> >>At 23:08 08/08/2007, philip.eardley@bt.com wrote: >>>[BB]> The unintended implication that all packets are either marked or not >>> > marked >>> > should also be carefully avoided. The draft needs to say explicitly >>>that >>> > "Admission (or Termination) marking will be an encoding of some >>> > combination >>> > of codepoints in the IP header to signal a varying fractional number >>>from >>> > a >>> > path of PCN-interior-nodes to a PCN-egress-node" >>> >>>[PE] I'm not sure this is accurate for either of the main categories of >>>marking algorithm (threshold marking [=step marking of cl-architecture], >>>or excess-rate-marking [where a mark means so many bits in excess]). (it >>>is true for ramp-marking of cl-architecture.) >> >>[BB] 1/ threshold marking >> >>As load builds, assuming traffic isn't pure CBR, a queue will very likley >>be oscillating up and down quite fast. Here's a picture at packet >>granularity that I did about a year ago to illustrate this: >> >> >> >>Even if you have a step marking threshold at some queue length (any >>positive horizontal line across the top graph), only a proportion of >>packet will be marked. >> >>I believe Anna's simulations of step vs ramp demonstrated they weren't >>that different, which is what I would expect. A ramp merely ensures there >>is a smooth transition from zero marking to full marking even if the >>traffic doesn't provide any randomness itself (pure CBR) or its variable >>but highly smoothed by statistical aggregation. >[MM] Threshold marking marks 0% of packets if the rate is significantly >below the critical threshold and 100% of the packets if it is >significantly above this threshold. Therefore, it also guearantees a fast >transition from the 0% marked packets regime to the 100% marked packets >regime when the rate increases. Certainly, there is a rate interval in >between where only some packets are marked due to rate variability, but I >hope that this does not create severe problems regarding under- or >overadmission for large traffic aggregations. [BB] The problem we were trying to solve with ramp marking was the reverse: we were looking for a marking algo that produced a smooth increase in marking over a wider range of loads. The edge nodes can always turn a smooth rise into a toggle at a specific threshold marking level. A smooth increase would extend the operating range to lower levels of aggregation, where the bit rate of one additional flow is not tiny relative to all the flows already in an aggregate between two edge nodes. With sharp threshold marking, you don't any marking even if the total of all flows already in the system are just below the threshold. Even adding some probing packets for the next flow may not make enough difference to the bit rate to see any marking. But when you add the next flow, marking might toggle to 100% (whether this is overadmission or not depends on whether the configured admission rate was set lower to allow for such a possibility). Often, at low aggregation, there's sufficient variability in the flows (e.g. silence suppression) to cause the virtual queue to rise and fall sufficiently to cross back and forth over the threshold and cause an intermediate marking level that could be used to avoid overadmitting the next flow. But there is still the pathological case of pure CBR flows. That's why we recommended ramp originally (or that's why I thought we did!): to produce a smooth (more controllable) transition, even if the traffic doesn't have any natural variability. However, the intention in writing ramp as the canonical algo in the cl-phb draft was never to say that ramp should be mandated. It was just one of the better tradeoffs if you were only thinking in terms of functionality - if you didn't have to worry about implementation and management. The wider tradeoff is that ramp requires one more parameter to be set and therefore one more parameter to be wrong some of the time. And not all current hardware can do a programmable marking "curve" anyway. >>[BB] 2/ Excess rate marking >> >>Surely the whole point here is to mark a proportion of packets to signify >>the amount of excess rate. So I don't quite understand how it will either >>be 0% or 100% marking? Am I missing something? > >[MM] I guess this applies for threshold marking only. Excess rate marking >leaves an amount of traffic with the token bucket rate unmarked. [BB] Good - we're agreed on this then. Cheers Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 21 00:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INLLd-0002nb-SX; Tue, 21 Aug 2007 00:28:09 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1INLLc-0002gG-EQ for pcn-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 00:28:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INLLb-0002e7-Ck for pcn@ietf.org; Tue, 21 Aug 2007 00:28:08 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INLLa-0007DB-Bo for pcn@ietf.org; Tue, 21 Aug 2007 00:28:07 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7L4S2V21298; Tue, 21 Aug 2007 04:28:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WGscoping decisions in an RFC?) Date: Tue, 21 Aug 2007 00:27:45 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511C386ED@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DC@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WGscoping decisions in an RFC?) Thread-Index: Acfbe49Y8L1MXEMmReG9vIjhsUHC8QDmBFigASWeMuA= References: <5.2.1.1.2.20070810174236.0314abe0@pop3.jungle.bt.co.uk> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3DC@E03MVZ1-UKDY.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org [Joe] I agree that the PCN mechanisms may be applied to more than one traffic class which is distinguished by DSCP. I thinks that will be sufficient as emergency/military services with PCN are currently out of scope with the charter of PCN WG. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 15, 2007 4:15 AM To: rbriscoe@jungle.bt.co.uk; Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WGscoping decisions in an RFC?) Regardless of the precedence issue for emergency/military use, there still could be more than one PCN class. Ie can imagine an operator offering 2 services, "important inelastic flows with PCN adm ctrl" and "less important inelastic flows with PCN adm ctrl" The architecture draft (currently) says: o The PCN mechanisms may be applied to more than one traffic class (which are distinguished by DSCP). > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: 10 August 2007 18:14 > To: Jozef Babiarz > Cc: PCN IETF list > Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss > WGscoping decisions in an RFC?) >=20 > Joe, >=20 > At 01:03 10/08/2007, Jozef Babiarz wrote: > >Bob, Michael, > >In TSVWG about two years ago, it was decided that flow precedence > >information and control of it is to be handle in higher layers and not > >by the transport layer. > > > >I believe that if we have precedence and normal traffic in the network > >that admission and flow termination of it is handled based on precedence > >information that is provided via signalling (SIP) during session setup > >or higher layers control protocol. The transport layer and the PCN > >mechanism is not precedence aware. >=20 > What exactly do you mean by "the tsvwg decided"? I don't think the tsvwg > (or the IETF) is in a position to decide how emergency services define the > use of PHBs for emergencies. I would have thought this is an issue to be > decided by governments and operators and there's no big standards > implication whichever way they choose. Why would the IETF want or need to > force a government's or operator's choice in this respect? The whole point > of Diffserv is that the codepoints are there to be used as operators > choose, with some standard ones. >=20 > Certainly I believe the DoD don't like identifying precendence traffic in > the data plane, as it might make it easier to target an attack at certain > data. But the DoD is but a small part of the possible policy space in this > area. >=20 > In general, the IETF does vendor standards. If anyone was going to touch > operational policy standards in the hot policy area of emergency services, > I doubt very much it would be the IETF, which doesn't have the > political/voting structures necessary for such a politically sensitive > subject. Instead, I would imagine the IETF should produce protocols that > cater for what seems a reasonable spectrum of likely policy choices. >=20 > There does seem to be a valid technical motivation for specifying > precedence both at the session/signalling layer and in the data plane. > While a disaster or some emergency is in progress, routing and signalling > will be continually being disrupted and trying to stabilise, leading to > possibly continual excess traffic at various points in the data plane. > Even > if the emergency services have the right to signalling precedence over > other flows, if the emergency is characterised by persistent or continuing > disruption (earthquakes, riots, wars, DoS attacks etc), the emergency > media may well still be unintelligible for extended periods while > signalling is trying to deal with the storm. So in some operational > regimes, data priority might be needed as well as signalling priority. To > ensure precedence traffic floats on top of the persistently choppy waves > of > other traffic. >=20 > Even if there was data plane precedence, PCN would not have to be > precedence-aware. But when designing PCN we have to be aware of the > possible combinatorial codepoint expansion. If we insisted that PCN is > encoded in 3 DSCPs (say), then anyone that wanted to use n DSCPs for EF, > would have to set aside 3 x n DSCPs for PCN. >=20 > However, I admit, I know very little about operational practices or > regulatory/military/emergency/government requirements around the world in > this respect. I'm just saying it seems unlikely that every government in > the world will have agreed on a signalling-only approach to precedence. >=20 > Anyone have any facts? >=20 >=20 > Bob >=20 > >Regards, Joe > >email:babiarz@nortel.com > >Telephone:613-763-6098 > >-----Original Message----- > >From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >Sent: July 25, 2007 8:54 AM > >To: Bob Briscoe > >Cc: PCN IETF list > >Subject: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG > >scoping decisions in an RFC?) > > > >Hi Bob, > > > > > >Bob Briscoe wrote: > > >>> Regarding emergency use: the charter says: > > >>> > > >>> (D) flows may have different precedence, but the applicability > > >>> of the PCN mechanisms for emergency use (911, GETS, WPS, > > >>> MLPP, etc.) is out of scope > > >>> > > >>> This could be interpreted in more than one way, but I interpret this > >as > > >>> saying that PCN-specific mechanisms will not take flow precedence > >into > > >>> account. Which is a different than saying that PCN cannot be used > >with > > >>> flow setup protocols/mechanisms that take flow precedence into > >account. > > >>> > > >> > > >> As soon as we have multiple PCN classes it might be useful to think > > >> about flow precedence especially with regard to admission and > > >> termination priority. Equal treatment of flows means that a highly > > >> critical telemedicine application has the same probability to be > > >> terminated as a "relatively" uncritcical VoIP call in case of a > > >> disaster. I read the passage in the way that it's not our job to > > >> define mechanisms for emergency use, but it is not prohibited to > > >> extend PCN towards multiple classes with different requirements > > >> although this is not the first thing to do. > > > > > > Michael, just to warn against your use of the word 'extend' PCN. > > > > > > For the avoidance of doubt, I think Steve's saying it is NOT in scope > > > to extend PCN towards multiple classes with different requirements, > > > but it is in scope for PCN to use (ie refer out to) other mechanisms > > > that satisfy different emergency reqs, and similarly I guess it would > > > be in scope to prove PCN doesn't stop these other mechanisms working. > > > > > > If I'm right, the txt in this arch draft is misleading and should be > > > changed. The _applicability_ of PCN mechs for emergency use is in > > > scope, but PCN-specific mechs for emergency use are out of scope. > > > >Sorry for using the word "extend", but I'm not sure whether I understand > > > >your answer correctly. We had the discussion about coexistence of > >several PCN- and non-PCN classes already several times on the list and > >it seemed to me that is an unsolved issue so far. When I say "extend > >PCN" I mean adapting the currently discussed single-PCN-class mechanisms > > > >to work in a multi-class environment with a pre-defined number of PCN > >classes. I do not talk about extending PCN for the need of specific > >applications. > > > >The existence of multiple PCN classes has some impact on encoding and > >possibly also on metering and marking, so this is a question that should > > > >be discussed before encoding is decided. As far as I can remember the > >general view was that the charter does not forbid several PCN classes, > >but it's not the first thing to be done. Are we in line or is your view > >that there is and will be only a single PCN class that is coupled with a > > > >single PHB? Maybe this is an issue for discussion at the meeting, at > >least to me, the answer of that question is not clear. > > > >Regards, > > > >Michael > > > > > > > > > > > > > Bob > > > > > > > > >> Regards, > > >> > > >> Michael > > >> > > >>> > > >>> Regards, > > >>> > > >>> = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > >>> Steven Blake > > >>> Ericsson/Redback Networks +1 919-472-9913 > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> PCN mailing list > > >>> PCN@ietf.org > > >>> https://www1.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 > > > > > > > >_______________________________________________________________________ _ > >____ > > > > > > Bob Briscoe, Networks Research Centre, BT > > > Research > > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > > > 645196 > > > >-- > >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://www1.ietf.org/mailman/listinfo/pcn >=20 > ________________________________________________________________________ __ > __ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 >=20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 22 04:18:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INlPp-000266-7d; Wed, 22 Aug 2007 04:18:13 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1INlPo-000261-KG for pcn-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 04:18:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INlPk-00025q-NA for pcn@ietf.org; Wed, 22 Aug 2007 04:18:08 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INlPg-00054Z-20 for pcn@ietf.org; Wed, 22 Aug 2007 04:18:08 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN600KYV1OP15@szxga04-in.huawei.com> for pcn@ietf.org; Wed, 22 Aug 2007 16:17:14 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN6007NK1OL6B@szxga04-in.huawei.com> for pcn@ietf.org; Wed, 22 Aug 2007 16:17:13 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN6009X51OL9Z@szxml03-in.huawei.com> for pcn@ietf.org; Wed, 22 Aug 2007 16:17:09 +0800 (CST) Date: Wed, 22 Aug 2007 16:17:09 +0800 From: Tina TSOU Subject: Re: [PCN] PCN architecture, new addressing sub-section To: pcn@ietf.org, babiarz@nortel.com, philip.eardley@bt.com Message-id: <013201c7e494$d5fe8b30$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3FE@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 1.2 (+) X-Scan-Signature: 7a9d8f61f7718176ef97b85bbcc64331 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0430465484==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0430465484== Content-type: multipart/alternative; boundary="Boundary_(ID_yUc/ty/AzH00JbPzd9eVaQ)" This is a multi-part message in MIME format. --Boundary_(ID_yUc/ty/AzH00JbPzd9eVaQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Phil, You are also right. Allowing Egress Node flow aware implies that allowing in Egress Node to establish such table as below. FLOW FLOW's Ingress node flow1 Ingress A flow2 Ingress A flow3 Ingress B flow4 Ingress B It is considered that such table could be rather big. Considering an Edge Node as both Ingress and Egress, It is a good idea to let both share the flow status. I support Phil. However, I feel that it makes sense only for the bi-directional symmetric flow, now, as a Edge node, the maintained flow status could be as below. FLOW Peer Edge Policies flow1 A XX flow2 A XX flow3 B XX flow4 B XX Each entry could be interpreted like that some flow passes me to a peer edge (Egress), or from peer edge (Ingress) reaches me. That's OK, as long as it is for bidirectional symmetric flow. PCN-ingress-nodes are flow-aware (required for policing purposes). In several deployment scenarios PCN-egress-nodes will also be flow aware. (Normally this adds no complexity since a PCN-boundary- node acts as both a PCN-ingress-node and as a PCN-egress-node.) If PCN-egress-node is not flow-aware, there is an optional method, i.e. form the symmetric cross-domain routing to derive flow and Ingress-Egress matching relationship. B. R. Tina ----- Original Message ----- From: philip.eardley@bt.com To: babiarz@nortel.com ; tena@huawei.com ; pcn@ietf.org Sent: Monday, August 20, 2007 3:37 PM Subject: RE: [PCN] PCN architecture, new addressing sub-section Joe, Will add something about probing to the addressing section. Tina, not entirely sure what you mean about merging. There is some text near the start of section 4 that may be useful? PCN-ingress-nodes are flow-aware (required for policing purposes). In several deployment scenarios PCN-egress-nodes will also be flow aware. (Normally this adds no complexity since a PCN-boundary- node acts as both a PCN-ingress-node and as a PCN-egress-node.) phil -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com] Sent: 15 August 2007 19:26 To: Tina TSOU; pcn@ietf.org; Eardley,PL,Philip,CXR9 R Subject: RE: [PCN] PCN architecture, new addressing sub-section See additional comments demarked with [Joe1] below. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------------------------------------------------------------------------------ From: Tina TSOU [mailto:tena@huawei.com] Sent: August 13, 2007 2:32 AM To: pcn@ietf.org; philip.eardley@bt.com; Babiarz, Jozef (CAR:0S03) Subject: Re: [PCN] PCN architecture, new addressing sub-section ----- Original Message ----- From: Jozef Babiarz To: philip.eardley@bt.com ; pcn@ietf.org Sent: Saturday, August 11, 2007 4:52 AM Subject: RE: [PCN] PCN architecture, new addressing sub-section See my comments below demarked with [Joe]. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ---------------------------------------------------------------------------- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: August 8, 2007 6:15 PM To: pcn@ietf.org Subject: [PCN] PCN architecture, new addressing sub-section This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about addressing: 5.7. Addressing PCN-nodes may need to know the address of other PCN-nodes: o in all cases PCN-interior-nodes don't need to know the address of any other PCN-nodes, except their next hop neighbours o in the cases of admission or termination decision by a PCN- boundary-node, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, at a minimum so that the PCN-ingress-node can be informed to enforce the admission decision through policing. The addressing information can be gathered from signalling, for example as described for RSVP in [I-D.lefaucheur-rsvp-ecn]. Alternatively, if PCN-traffic is always tunnelled across the PCN-domain, then the PCN-ingress- node's address is simply the source address of the outer packet header. [Joe] I believe that the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified "... enforce the admission and flow termination decision through policing." [end] [Tina: sounds excellent.] [Joe] Would also like to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. "Another method that may be used to discover and exchange address information between PCN-boundary-nodes is through probing. The PCN-ingerss-node using the IP header information of the flow to be admitted generates and sends probe packets that can easily be detected by the PCN-egress-node. The sent probe packets contain as payload the address of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow." [end] [Tina: I found there is similarity between this probe method and RSVP method. The PCN ingress node places its address in the probe packet or RSVP PATH message, the interior nodes doesn't care about these packets, the PCN egress node could associate the flow with the correct PCN ingress node after extracting the address of the PCN ingress node embedded in the probe packet or RSVP PATH message. These kinds of methods have a disadvantage: it's hard for the egress node to merge the flows. A PCN egress node may create a mapping table like follows: [Joe1] I do not see a need to merge flows in egress node for admission control if probing is used. Also, no need to build and maintain ingress-egress flow aggregating tables or perform rate measurements of marked or unmarked PCN traffic if the marking as in 3sm draft is used. [end] FLOW FLOW's Ingress node flow1 Ingress A flow2 Ingress A flow3 Ingress B flow4 Ingress B If there are too many flows, the table may be very large. One option to solve addressing of PCN-boundary node may be to use symmetric route. For example, supposing IBGP is running on the PCN-boundary node: 1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress B----2.2.2.0/24 IBGP could tell the egress node B that it has to go through PCN ingress A to reach 1.1.1.0/24, the egress node B could then regard a packet from 1.1.1.0/24 will come through ingress A, given a symmetric route scenario. The disadvantage of this option may be the requirement of symmetric route. The advantage of this option is that merged table item may be supported. Network Network's Ingress node 1.1.1.0/24 Ingress A] o in the cases of admission or termination decision by a central control node, the PCN-egress-node needs to be configured with the address of the centralised node. In addition, depending on the exact deployment scenario and its signalling, the centralised node may need to know the addresses of the PCN-ingress-node and PCN- egress-node, and the PCN-egress-node know the address of the PCN- ingress-node. NOTE: Consideration of the centralised case is out of scope of the initial PCN WG Charter. [Joe] I think we need a bit more discussion about the central control node. I'm thinking of something like a PDP where pre-congestion information is sent to and after verifying the policy the result is sent to PCN-ingress-node to care out the action. For this scenario, the PCN-boundary-nodes need to be provisioned with the address of the central policy control node. [end] [Joe] Can the proponents of the central control node expand a bit more on how this will work? [end] [Tina: A centralized node will not burden the addressing of PCN-boundary nodes. To make metering, the egress node always has to know the ingress node address a flow associated. A centralized node makes the egress node doesn't need to notify the pre-congestion information (CLE) to the ingress node, instead, the egress node will send it to the centralized node. So the address of the centralized node has to be provisioned on the egress node. When the egress node notifies the CLE to the centralized node, it has to send the ingress node address associated the CLE. So the centralized would know the address of every PCN boundary node.] (I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder if the description of the centralised node case is too long, as the case is strictly out of scope.) ---------------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --Boundary_(ID_yUc/ty/AzH00JbPzd9eVaQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi Phil,
You are also right.
Allowing Egress = Node flow=20 aware implies that allowing in Egress Node to establish such table as=20 below.
FLOW    FLOW's Ingress = node
flow1   =20 Ingress A
flow2    Ingress = A
flow3   =20 Ingress B
flow4    Ingress B
It is considered that = such=20 table could be rather big.
 
Considering an Edge Node as both = Ingress and=20 Egress, It is a good idea to let both share the flow status. I support = Phil.=20 However, I feel that it makes sense only for the bi-directional = symmetric flow,=20 now, as a Edge node, the maintained flow status could be as=20 below.
FLOW Peer=20 Edge Policies
flow1 A  XX
flow2 A &nb= sp;XX
flow3 B  XX
flow4 B  XX
Each= =20 entry could be interpreted like that some flow passes me to a peer edge=20 (Egress), or from peer edge (Ingress) reaches me. That=92s OK, as long = as it is=20 for bidirectional symmetric flow.  
 
PCN-ingress-nodes are flow-aware = (required for=20 policing purposes).  In
      several=20 deployment scenarios PCN-egress-nodes will also be=20 flow
      aware.  (Normally this adds = no=20 complexity since a PCN-boundary-
      node = acts as=20 both a PCN-ingress-node and as a PCN-egress-node.)
 
If PCN-egress-node is not flow-aware, = there is an=20 optional method, i.e. form the symmetric cross-domain routing to derive = flow and=20 Ingress-Egress matching relationship.
B. R.
Tina
----- Original Message -----
From:=20 philip.eardley@bt.com
To: babiarz@nortel.com ; tena@huawei.com ; pcn@ietf.org =
Sent: Monday, August 20, 2007 = 3:37=20 PM
Subject: RE: [PCN] PCN = architecture, new=20 addressing sub-section

Joe,=20

Will add = something=20 about probing to the addressing section.

 

Tina, not = entirely=20 sure what you mean about merging. There is some text near the start of = section=20 4 that may be useful?

 

PCN-ingress-nodes are=20 flow-aware (required for policing purposes).  = In

     =20 several deployment scenarios PCN-egress-nodes will also be=20 flow

     =20 aware.  (Normally this adds no complexity since a=20 PCN-boundary-

     =20 node acts as both a PCN-ingress-node and as a=20 PCN-egress-node.)

 

phil

 

-----Original=20 Message-----
From: = Jozef=20 Babiarz [mailto:babiarz@nortel.com]
Sent: 15 August 2007 = 19:26
To: Tina TSOU; pcn@ietf.org;=20 Eardley,PL,Philip,CXR9 R
Subject: RE: [PCN] PCN = architecture, new=20 addressing sub-section

 

See = additional=20 comments demarked with [Joe1] below.

 

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

From: Tina TSOU=20 [mailto:tena@huawei.com]
Sent: August 13, 2007 2:32 = AM
To: pcn@ietf.org; = philip.eardley@bt.com;=20 Babiarz, Jozef (CAR:0S03)
Subject: Re: [PCN] PCN = architecture, new=20 addressing sub-section

 

 

----- Original Message = -----=20

From: Jozef Babiarz =

Sent: Saturday, August 11, = 2007 4:52=20 AM

Subject: RE: [PCN] PCN = architecture, new=20 addressing sub-section

 

See my = comments=20 below demarked with [Joe].

 

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

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:15=20 PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture, new=20 addressing sub-section

 

This is to flag up that I wrote a new = sub-section=20 (in Section 5, Detailed functional architecture) about=20 addressing:

 

5.7.  Addressing

 

   PCN-nodes may need to know = the address=20 of other PCN-nodes:

 

   o  in all cases = PCN-interior-nodes=20 don't need to know the address of

      any other = PCN-nodes,=20 except their next hop neighbours

 

   o  in the cases of = admission or=20 termination decision by a PCN-

      = boundary-node, the=20 PCN-egress-node needs to know the address of

      the = PCN-ingress-node=20 associated with a flow, at a minimum so that

      the = PCN-ingress-node=20 can be informed to enforce the admission

      decision = through=20 policing.  The addressing information can be

      gathered = from=20 signalling, for example as described for RSVP in

     =20 [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic=20 is

      always = tunnelled=20 across the PCN-domain, then the PCN-ingress-

      node's = address is=20 simply the source address of the outer packet

     =20 header.

[Joe] I believe that the=20 PCN-ingress-node should enforce both the admission and flow = termination=20 decisions. So would suggest that the above text be modified =93... = enforce the=20 admission and flow termination decision through policing.=94=20 [end]

[Tina: = sounds=20 excellent.]

 

[Joe] Would also like to add = that=20 probing can be used to discover and exchange address information of=20 PCN-boundary-nodes. =93Another method that may be used to discover = and=20 exchange address information between PCN-boundary-nodes is through = probing.=20 The PCN-ingerss-node using the IP header information of the flow to = be=20 admitted generates and sends probe packets that can easily be = detected by=20 the PCN-egress-node. The sent probe packets contain as payload the = address=20 of the PCN-ingress-node so that the PCN-egress-node knows where to = send the=20 pre-congestion information for that flow.=94 [end]

[Tina: I = found=20 there is similarity between this probe method and RSVP method. The = PCN=20 ingress node places its address in the probe packet or RSVP PATH = message,=20 the interior nodes doesn't care about these packets, the PCN egress = node=20 could associate the flow with the correct PCN ingress node after = extracting=20 the address of the PCN ingress node embedded in the probe packet or = RSVP=20 PATH message.
These kinds of methods have a disadvantage: it's = hard for=20 the egress node to merge the flows. A PCN egress node may create a = mapping=20 table like follows:

[Joe1] I = do not see=20 a need to merge flows in egress node for admission control if = probing is=20 used. Also, no need to build and maintain ingress-egress flow = aggregating=20 tables or perform rate measurements of marked or unmarked PCN = traffic if the=20 marking as in 3sm draft is used. [end]


FLOW    FLOW's=20 Ingress node
flow1    Ingress=20 A
flow2    Ingress=20 A
flow3    Ingress=20 B
flow4    Ingress B
If there are too many = flows,=20 the table may be very large.
One option to solve addressing of=20 PCN-boundary node may be to use symmetric route. For example, = supposing IBGP=20 is running on the PCN-boundary node:
1.1.1.0/24----PCN Ingress = A---PCN=20 interior node-----PCN Egress B----2.2.2.0/24
IBGP could tell the = egress=20 node B that it has to go through PCN ingress A to reach 1.1.1.0/24, = the=20 egress node B could then regard a packet from 1.1.1.0/24 will come = through=20 ingress A, given a symmetric route scenario.
The disadvantage of = this=20 option may be the requirement of symmetric route. The advantage of = this=20 option is that merged table item may be=20 supported.
Network   Network's Ingress=20 node
1.1.1.0/24   Ingress A] 

 

   o  in the cases of = admission or=20 termination decision by a central

      control = node, the=20 PCN-egress-node needs to be configured with the

      address of = the=20 centralised node.  In addition, depending on = the

      exact = deployment=20 scenario and its signalling, the centralised node

      may need to = know the=20 addresses of the PCN-ingress-node and PCN-

      = egress-node, and the=20 PCN-egress-node know the address of the PCN-

      = ingress-node. =20 NOTE: Consideration of the centralised case is out

      of scope of = the=20 initial PCN WG Charter.

 

[Joe] I think we need a bit = more=20 discussion about the central control node. I=92m thinking of = something like a=20 PDP where pre-congestion information is sent to and after verifying = the=20 policy the result is sent to PCN-ingress-node to care out the = action. For=20 this scenario, the PCN-boundary-nodes need to be provisioned with = the=20 address of the central policy control node. [end]

 

[Joe] Can the proponents = of the=20 central control node expand a bit more on how this will work?=20 [end]

[Tina: A = centralized node will not burden the addressing of PCN-boundary = nodes. To=20 make metering, the egress node always has to know the ingress node = address a=20 flow associated. A centralized node makes the egress node doesn=92t = need to=20 notify the pre-congestion information (CLE) to the ingress node, = instead,=20 the egress node will send it to the centralized node. So the address = of the=20 centralized node has to be provisioned on the egress node. When the = egress=20 node notifies the CLE to the centralized node, it has to send the = ingress=20 node address associated the CLE. So the centralized would know the = address=20 of every PCN boundary node.]

 

(I'm not completely happy with it. I'm not = sure it=20 captures sufficiently the discussion there was a month or two back = about=20 different ways the egress could know the ingress address. Also, I = wonder if=20 the description of the centralised node case is too long, as the = case is=20 strictly out of scope.)

 

 

_______________________________________________
PCN=20 mailing=20 = list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn=

--Boundary_(ID_yUc/ty/AzH00JbPzd9eVaQ)-- --===============0430465484== 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://www1.ietf.org/mailman/listinfo/pcn --===============0430465484==-- From pcn-bounces@ietf.org Thu Aug 23 15:28:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOIM1-0000EC-Mm; Thu, 23 Aug 2007 15:28:29 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IOIM0-0000E6-U4 for pcn-confirm+ok@megatron.ietf.org; Thu, 23 Aug 2007 15:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOILz-0000Dw-DH for pcn@ietf.org; Thu, 23 Aug 2007 15:28:27 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOILx-00089Z-Jg for pcn@ietf.org; Thu, 23 Aug 2007 15:28:26 -0400 Received: by wr-out-0506.google.com with SMTP id 70so443230wra for ; Thu, 23 Aug 2007 12:28:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eZ5d0KHtiWp4HUrZTkHrjRB0LA3eTCmaXCYjhOnJagufg+TMLOGv9cBmSIBy9F9c2LUS1Y4qAVr+j6/Q3Zl7++WGm6Gbk3puKi8ccczCFJS19m+jqFCzdaNXfPio5gfjVezVvnylf+Y0ZZ2p/NZUQha+/EoAc9hrhXNnm36IKrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PVYGWTRG46P2DaEV8Ru3A1FU0Piog1KJhSlQrpJZuGFbRnXt8+wNaojHZR/vYYnxumPbdGahw44Gpylr5olqLeETX7aDwSaxNTXsjsejCm5zxSeG8GoAItd950on6r0HfXg+f1V7ao8L2U7BNyup6RqsRrgNXTBDYVIFYH8TBDo= Received: by 10.90.90.16 with SMTP id n16mr7238866agb.1187897304970; Thu, 23 Aug 2007 12:28:24 -0700 (PDT) Received: by 10.100.31.1 with HTTP; Thu, 23 Aug 2007 12:28:24 -0700 (PDT) Message-ID: Date: Thu, 23 Aug 2007 12:28:24 -0700 From: "Lachlan Andrew" To: "Bob Briscoe" Subject: Re: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking In-Reply-To: <5.2.1.1.2.20070820115053.03b83150@pop3.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> <46BD5E0D.6050803@informatik.uni-wuerzburg.de> <5.2.1.1.2.20070820115053.03b83150@pop3.jungle.bt.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: pcn@ietf.org, Sammy Chan X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: l.andrew@ieee.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Greetings, On 20/08/07, Bob Briscoe wrote: > > [BB] > we were looking for a marking algo that produced a smooth increase in > marking over a wider range of loads. The edge nodes can always turn a > smooth rise into a toggle at a specific threshold marking level. > > With sharp > threshold marking, you don't any marking even if the total of all flows > already in the system are just below the threshold. Even adding some > probing packets for the next flow may not make enough difference to the bit > rate to see any marking. But when you add the next flow, marking might > toggle to 100% Hear, hear! I believe that the marking scheme should carry as much information as possible about the network state, and that thresholding should be done as late as possible (at the decision-making end-points). The more information the decision-making entity has, better the decisions it can make. If things like thresholding are done where the admission decisions are made, there is also a smoother upgrade path for changes in the admission rules. For example, an operator may want to apply different thresholds applied to different types of incoming calls. If routers provide a single threshold, this can't be implemented at a later stage. Similarly, an operator may want to admit a certain percentage of traffic dependent on the congestion level, rather than admitting all or none. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 24 02:05:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSIp-0002Pn-4q; Fri, 24 Aug 2007 02:05:51 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IOSIo-0002Pg-5k for pcn-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 02:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSIn-0002PY-Rx for pcn@ietf.org; Fri, 24 Aug 2007 02:05:49 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOSIm-0007HM-9V for pcn@ietf.org; Fri, 24 Aug 2007 02:05:49 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7O65Ern030415; Fri, 24 Aug 2007 09:05:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 09:05:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 09:05:19 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 09:05:19 +0300 Received: from [192.168.255.2] (essapo-nirac25363.europe.nokia.com [10.162.253.63]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7O65GBO023706; Fri, 24 Aug 2007 09:05:17 +0300 In-Reply-To: References: <5.2.1.1.2.20070724140627.03c06a58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070810181633.03ea2a58@pop3.jungle.bt.co.uk> <46BD5E0D.6050803@informatik.uni-wuerzburg.de> <5.2.1.1.2.20070820115053.03b83150@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <131F47B5-9536-49B7-924D-03CDB5E98D47@nokia.com> From: Lars Eggert Subject: Re: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Date: Fri, 24 Aug 2007 09:04:59 +0300 To: l.andrew@ieee.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Aug 2007 06:05:19.0099 (UTC) FILETIME=[BF9054B0:01C7E614] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: pcn@ietf.org, Sammy Chan X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1862453105==" Errors-To: pcn-bounces@ietf.org --===============1862453105== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--825098019; protocol="application/pkcs7-signature" --Apple-Mail-2--825098019 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-8-23, at 22:28, ext Lachlan Andrew wrote: > I believe that the marking scheme should carry as much information as > possible about the network state, and that thresholding should be done > as late as possible (at the decision-making end-points). The more > information the decision-making entity has, better the decisions it > can make. I completely agree. A marking scheme that attempts to convey the maximum possible information about the network state is also much more likely to be future-proof, i.e., support uses or extensions of PCN that aren't currently on the plate for standardization. > If things like thresholding are done where the admission decisions are > made, there is also a smoother upgrade path for changes in the > admission rules. For example, an operator may want to apply different > thresholds applied to different types of incoming calls. If routers > provide a single threshold, this can't be implemented at a later > stage. Similarly, an operator may want to admit a certain percentage > of traffic dependent on the congestion level, rather than admitting > all or none. Lars (with my individual contributor hat on) --Apple-Mail-2--825098019 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA4MjQwNjA0NTlaMCMGCSqGSIb3DQEJBDEWBBSIXdEYkHkH77oD ueQpTIRS2YAmrDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAQMcW/sWqiVLbr1xdpo1QuVVRlgCHZon1CAfiZxN5iSAHU+O6aGVr Fzm+wUz5M9PUJGhjH1wOnp95T8TlO0zdEnStqIf7r/eOZEKb1Biu1Zc6fBZtYEMrBVgmvEFf9mzI zNI4Ict6P2QWUtlH5/DY1Kt4ekiDzOqHpdWvGGZUp1s2vGDZP0Y38CMwS1UiQBSfOZcGET0DX9sQ 7rqYjzLrENabB2CN9rf5v/AAApn95XCW7xHiWiEdVDce27mIHJpZif6rmZxQKH2bbeSNsTlbxxxE zb/yZr/H1ToYlPDBQM3VnM/hU0w25mjFZgBZsMuDSpxUGw9ZmDlABrtNITMAzwAAAAAAAA== --Apple-Mail-2--825098019-- --===============1862453105== 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://www1.ietf.org/mailman/listinfo/pcn --===============1862453105==-- From pcn-bounces@ietf.org Fri Aug 24 03:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOTHp-0004Ug-Dq; Fri, 24 Aug 2007 03:08:53 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IOTHo-0004UZ-2S for pcn-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 03:08:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOTHk-0004UN-96 for pcn@ietf.org; Fri, 24 Aug 2007 03:08:48 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOTHj-00022u-NC for pcn@ietf.org; Fri, 24 Aug 2007 03:08:48 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 24 Aug 2007 09:08:44 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Aug 2007 09:08:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Date: Fri, 24 Aug 2007 09:08:42 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Thread-Index: AcflvCvM2BkuFxP2SVyXVFSEza8KfAAXv2cQ From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 24 Aug 2007 07:08:43.0906 (UTC) FILETIME=[9B67CE20:01C7E61D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: pcn@ietf.org, eeschan@cityu.edu.hk X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lachlan, Bob, you both seem to agree that ramp marking is the best solution.=20 Picking up Lachlan's pretty sound arguments on different thresholds=20 for different types of incoming calls - what you describe is=20 estimating the available (not consumed) PCN bandwidth rather than=20 just a "pre congestion notification", I think.=20 If there's a simple solution to realise this idea, PCN should=20 investigate it. This could be helpful if there's a new call to be=20 admitted and no PCN flow exists between two gateways. The question=20 then would be, whether a certain bandwidth is available, rather=20 than "any congestion visible". Regards, Ruediger |Lachlan wrote: |I believe that the marking scheme should carry as much information as |possible about the network state, and that thresholding should be done |as late as possible (at the decision-making end-points). The more |information the decision-making entity has, better the decisions it |can make. | |If things like thresholding are done where the admission decisions are |made, there is also a smoother upgrade path for changes in the |admission rules. For example, an operator may want to apply different |thresholds applied to different types of incoming calls. If routers |provide a single threshold, this can't be implemented at a later |stage. Similarly, an operator may want to admit a certain percentage |of traffic dependent on the congestion level, rather than admitting |all or none. |Bob wrote: |[BB] The problem we were trying to solve with ramp marking was the=20 |reverse:=20 |we were looking for a marking algo that produced a smooth increase in=20 |marking over a wider range of loads. The edge nodes can always turn a=20 |smooth rise into a toggle at a specific threshold marking level. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 24 18:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOhHo-0000LB-IO; Fri, 24 Aug 2007 18:05:48 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IOhHm-0000EE-62 for pcn-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 18:05:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOhHl-0000Di-RZ for pcn@ietf.org; Fri, 24 Aug 2007 18:05:45 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOhHl-0004U8-Fj for pcn@ietf.org; Fri, 24 Aug 2007 18:05:45 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l7OMAEDP032244; Fri, 24 Aug 2007 17:10:14 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 17:05:41 -0500 Received: from [147.117.169.108] ([147.117.169.108]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 17:05:40 -0500 From: Steven Blake To: philip.eardley@bt.com In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC38F@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC38F@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Fri, 24 Aug 2007 18:05:40 -0400 Message-Id: <1187993140.1512.124.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2007 22:05:40.0950 (UTC) FILETIME=[E8DD0760:01C7E69A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: pcn@ietf.org Subject: [PCN] ECN & EF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org [Chair hat off] Philip et. al., I see that in Sec. 3.5 of the architecture draft, you assume: - Packets with ECN CE markings arriving at a PCN ingress router are automatically dropped. - EF PHB is assumed for all PCN-managed traffic. I asked previously if we needed to make the first assumption when ECN header bits are NOT being used to signal PCN markings. As far as I know the answer is no. So I would suggest you either (a) write up a rationale for assuming this, or (b) mention that it is only an issue when re-using the ECN bits for PCN marking (which we haven't decided yet). Regarding the second assumption, it might or might not be a sensible idea in most circumstances, but I cannot think of a rationale as to why it is required. So I suggest that you also come up with a rationale for this assumption, or weaken the statement in the draft. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 27 10:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfPK-0002fR-Ia; Mon, 27 Aug 2007 10:17:34 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IPfPJ-0002fK-Ex for pcn-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 10:17:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfPJ-0002fC-3b for pcn@ietf.org; Mon, 27 Aug 2007 10:17:33 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPfPI-0004zt-Ef for pcn@ietf.org; Mon, 27 Aug 2007 10:17:33 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7REHBF16813; Mon, 27 Aug 2007 14:17:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Date: Mon, 27 Aug 2007 10:17:08 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646511DC4B87@zcarhxm1.corp.nortel.com> In-Reply-To: <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Thread-Index: AcflvCvM2BkuFxP2SVyXVFSEza8KfAAXv2cQAIffmKA= References: <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pcn@ietf.org, eeschan@cityu.edu.hk X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I think there is a bit more to this issue than just different levels of pre-congestion. For admission control the challenge for PCN is to find out how much new traffic can be added on to a specific link or path and not to determine the level of congestion. The purpose of admission control is to prevent congestion of the service class on link that forwards PCN traffic. PCN is deployed in Diffserv networks, with the understanding that PCN traffic is forwarded using priority scheduling. Voice with silence suppression plus calls naturally ending as well new calls being added generates highly variable traffic. The marking by interior node to indicate that PCN admission threshold is exceeded or not, needs to be quick to reflect true traffic levels. Analysis of the marking density and control of response to the marking can be handled at the edges. The proposed marking scheme in draft-babiarz-pcn-3sm-00.txt for admission control, produces the following behavior, when PCN traffic is fare below the admission stop threshold, no packets are marked. As the variable traffic increases and some packets exceed the token bucket rate (admission stop threshold) they are marked. If additional new traffic is allowed to be admitted on to the link, more packets will exceed the token bucket rate therefore marking density increases possibly until all packets are marked. However, for pure and stable CBR traffic you will get a step marking (on-off) where the transition from no marking to all packets marked being quick. =20 My view is that PCN should work equally well regardless of the number of flows in an ingress-egress aggregate from one to many flows, as well should work without the need for ingress-egress aggregation concept. The so called on-off marking approach is not that dependent on the rate of ingress-egress traffic meaning that edge node will be able to determine if new flow should be admitted based on low bit rate (probe or single voice flow) or high bit rate flow(s) passing through the pre-congested link. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: August 24, 2007 3:09 AM To: l.andrew@ieee.org; rbriscoe@jungle.bt.co.uk Cc: pcn@ietf.org; eeschan@cityu.edu.hk Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Lachlan, Bob, you both seem to agree that ramp marking is the best solution.=20 Picking up Lachlan's pretty sound arguments on different thresholds=20 for different types of incoming calls - what you describe is=20 estimating the available (not consumed) PCN bandwidth rather than=20 just a "pre congestion notification", I think.=20 If there's a simple solution to realize this idea, PCN should=20 investigate it. This could be helpful if there's a new call to be=20 admitted and no PCN flow exists between two gateways. The question=20 then would be, whether a certain bandwidth is available, rather=20 than "any congestion visible". Regards, Ruediger |Lachlan wrote: |I believe that the marking scheme should carry as much information as |possible about the network state, and that thresholding should be done |as late as possible (at the decision-making end-points). The more |information the decision-making entity has, better the decisions it |can make. | |If things like thresholding are done where the admission decisions are |made, there is also a smoother upgrade path for changes in the |admission rules. For example, an operator may want to apply different |thresholds applied to different types of incoming calls. If routers |provide a single threshold, this can't be implemented at a later |stage. Similarly, an operator may want to admit a certain percentage |of traffic dependent on the congestion level, rather than admitting |all or none. |Bob wrote: |[BB] The problem we were trying to solve with ramp marking was the=20 |reverse:=20 |we were looking for a marking algo that produced a smooth increase in=20 |marking over a wider range of loads. The edge nodes can always turn a=20 |smooth rise into a toggle at a specific threshold marking level. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 27 11:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgY8-0002PZ-JO; Mon, 27 Aug 2007 11:30:44 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IPgY7-0002PE-Ez for pcn-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 11:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgY7-0002Ow-4Z for pcn@ietf.org; Mon, 27 Aug 2007 11:30:43 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPgY5-0004CD-Ob for pcn@ietf.org; Mon, 27 Aug 2007 11:30:43 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l7RFanZX014813 for ; Mon, 27 Aug 2007 10:36:49 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:30:40 -0500 Received: from [147.117.169.108] ([147.117.169.108]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:30:40 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-AD3EFbwiC3ydehlEpJI0" Organization: Ericsson IP Infrastructure Date: Mon, 27 Aug 2007 11:30:40 -0400 Message-Id: <1188228640.29223.20.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 27 Aug 2007 15:30:40.0404 (UTC) FILETIME=[3979F540:01C7E8BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [PCN] [Fwd: Nomcom 2007-8: Please nominate candidates for IESG and IAB positions (Deadline: Sep 10, 2007)] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --=-AD3EFbwiC3ydehlEpJI0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Forwarding for wider dissemination ... tell your friends. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-AD3EFbwiC3ydehlEpJI0 Content-Disposition: inline Content-Description: Forwarded message - Nomcom 2007-8: Please nominate candidates for IESG and IAB positions (Deadline: Sep 10, 2007) Content-Type: message/rfc822 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw720.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 14:44:00 -0500 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 14:43:59 -0500 Received: from esealmw127.eemea.ericsson.se ([130.100.184.162]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 21:43:54 +0200 Received: from mailgw2.ericsson.se ([193.180.251.37]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 21:43:54 +0200 Received: from mailgw2.ericsson.se (unknown [127.0.0.1]) by mailgw2.ericsson.se (Symantec Mail Security) with ESMTP id 40FC820299; Thu, 23 Aug 2007 21:43:54 +0200 (CEST) X-AuditID: c1b4fb25-adf63bb000000830-53-46cde3791901 Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw2.ericsson.se (Symantec Mail Security) with ESMTP id D699C20554; Thu, 23 Aug 2007 21:43:53 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOIar-0002KX-NU; Thu, 23 Aug 2007 15:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOIaq-0002KM-EG for wgchairs@ietf.org; Thu, 23 Aug 2007 15:43:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOIao-0000JV-V7 for wgchairs@ietf.org; Thu, 23 Aug 2007 15:43:48 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7NJhjH7026072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Aug 2007 12:43:45 -0700 Received: from [10.50.72.93] (qconnect-10-50-72-93.qualcomm.com [10.50.72.93]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7NJhXlt027081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Aug 2007 12:43:34 -0700 Message-ID: <46CDE364.9090507@qualcomm.com> Date: Thu, 23 Aug 2007 12:43:32 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: wgchairs@ietf.org, rgchairs@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: Nomcom 2007-8: Please nominate candidates for IESG and IAB positions (Deadline: Sep 10, 2007) X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: wgchairs-bounces@ietf.org X-Brightmail-Tracker: AAAAAA== Return-Path: wgchairs-bounces@ietf.org X-OriginalArrivalTime: 23 Aug 2007 19:43:54.0401 (UTC) FILETIME=[F026E910:01C7E5BD] Content-Transfer-Encoding: 7bit Hi all, We have received very few nominations at the moment and among those very few accepted. If you have been thinking of nominating someone, please do so as soon as possible. The deadline is Sep 10, 2007, but please nominate soon to give the candidates sufficient time to fill in the questionnaires. Self nominations are permitted and encouraged. Please nominate at https://tools.ietf.org/group/nomcom/07/ or send an email to nomcom07@ietf.org or to me ldondeti@qualcomm.com. thanks, Lakshminath --=-AD3EFbwiC3ydehlEpJI0 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://www1.ietf.org/mailman/listinfo/pcn --=-AD3EFbwiC3ydehlEpJI0-- From pcn-bounces@ietf.org Wed Aug 29 03:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQIEC-0006zr-AY; Wed, 29 Aug 2007 03:44:40 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQIEB-0006zm-CB for pcn-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 03:44:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQIE7-0006zd-FZ for pcn@ietf.org; Wed, 29 Aug 2007 03:44:35 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQIE6-0008AE-QV for pcn@ietf.org; Wed, 29 Aug 2007 03:44:35 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:44:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Aug 2007 08:44:33 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC443@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1187993140.1512.124.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECN & EF Thread-Index: AcfmmutUuJa7E4aQScGJrj/D0+aK0ADcgBxA From: To: X-OriginalArrivalTime: 29 Aug 2007 07:44:33.0710 (UTC) FILETIME=[70DA9CE0:01C7EA10] X-Spam-Score: 1.8 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pcn@ietf.org Subject: [PCN] RE: ECN & EF X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Steven, =20 Thanks - my perspective is in-line phil > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: 24 August 2007 23:06 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: ECN & EF >=20 > [Chair hat off] >=20 > Philip et. al., >=20 > I see that in Sec. 3.5 of the architecture draft, you assume: >=20 > - Packets with ECN CE markings arriving at a PCN ingress router > are automatically dropped. >=20 > - EF PHB is assumed for all PCN-managed traffic. >=20 > I asked previously if we needed to make the first assumption when ECN > header bits are NOT being used to signal PCN markings. As far as I know > the answer is no. So I would suggest you either (a) write up a > rationale for assuming this, or (b) mention that it is only an issue > when re-using the ECN bits for PCN marking (which we haven't decided > yet). Yes, I think your option b) is true. I'll modify this section to say this. >=20 > Regarding the second assumption, it might or might not be a sensible > idea in most circumstances, but I cannot think of a rationale as to why > it is required. So I suggest that you also come up with a rationale for > this assumption, or weaken the statement in the draft. It's basically Assumption 2 (Section 3.2), "We assume that PCN-packets come from real time applications generating inelastic traffic [Shenker] like voice and video requiring low delay, jitter and packet loss, for example the Controlled Load Service, [RFC2211], and the Telephony service class, [RFC4594]." I don't think the EF PHB is intended to say anything different (is that true?), although you could argue they're not the same.=20 The justification in S3.2 says: "This assumption is to help focus the effort where it looks like PCN would be most useful, ie the sorts of applications where per flow QoS is a known requirement." this is true, although personally I think there's more to it than that - we don't really understand how the 'Many flows' assumption (Section 3.3) works for rate adaptive traffic. Compared with VBR traffic, rate adaptive tends to have much coarser changes of rate (bigger jumps, sticks at new rate for longer time), which probably makes it harder to get nicely behaving aggregated traffic. The other thing for rate adaptive traffic is to imagine if the PCN-domain is the part of the end-to-end path with the bandwidth constraint. One could imagine after flows had been admitted that the rates start adapting upwards. There would be no pkt drops to trigger the sources to adapt their rates downwards, and so flow termination would eventually kick in. I think the safety margins you'd need to allow would be greater than for VBR sources. However, we haven't (as far as I know) investigated how much harder rate adaptive sources would be for PCN than VBR ones (whether you just have to be more cautious and allow bigger safety margins, or whether it doesn't really work). Hence the assumption in S3.2. So my suggestion would be to keep the statement about EF PHB but add a reference to S3.2 and say something like "it isn't intended to be saying anything different to this" Comments? =20 >=20 >=20 > Regards, >=20 > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 29 04:55:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJKl-0000UJ-7o; Wed, 29 Aug 2007 04:55:31 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQJKj-0000S2-1i for pcn-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 04:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJKi-0000Q2-HC for pcn@ietf.org; Wed, 29 Aug 2007 04:55:28 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQJKg-0000px-UL for pcn@ietf.org; Wed, 29 Aug 2007 04:55:28 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 09:55:26 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 09:55:26 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1188377724563; Wed, 29 Aug 2007 09:55:24 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7T8tINQ021121; Wed, 29 Aug 2007 09:55:22 +0100 Message-Id: <5.2.1.1.2.20070829094927.039520d0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 29 Aug 2007 09:55:18 +0100 To: "Geib, Ruediger" From: Bob Briscoe Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking In-Reply-To: <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte .t-com.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 29 Aug 2007 08:55:26.0221 (UTC) FILETIME=[578C4BD0:01C7EA1A] X-Spam-Score: -1.0 (-) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: pcn@ietf.org, l.andrew@ieee.org, eeschan@cityu.edu.hk X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger, I was preparing an answer to both you & Joe yesterday, but the one to Joe needs to be a bit more involved, so below is my response to your point, and I'll get back to Joe next... Pre-congestion notification is a form of estimating available bandwidth for the Diffserv class - they aren't mutually exclusive. I'll explain using an example of three aggregates crossing a link: a) option | b) option ____________________________|______________________________________________ load from available | percent PCN marking share of ingress capacity | PCN threshold available | (constant) capacity | 3.0M __ __ 495k | 6% 15% (15%-6%)x3.0M = 270k \ / | 2.0M ---+----+--- 495k | 6% 15% (15%-6%)x2.0M = 180k __/ \__ | 500k 495k | 6% 15% (15%-6%)x500k = 45k ____ Total available capacity = 495k You get the same answer both ways but neither is meaningful. The question is, which is better: a) telling all edge nodes 495k is available (even tho no more than one can use any part of it at a time)? or b) telling all edge nodes they can each send 9% (=15%-6%) more than they are currently sending (when they are all unlikely to do so at the same time but they might)? In both cases, no single edge node knows how much extra traffic it can send because it doesn't know how many other nodes might be about to do the same: a) each node should not add 495k in case others do too b) each node will probably think it can add more than its share of available capacity, because not all other nodes are likely to in the next round trip time. In practice there may be anything from 0 to 10,000s of aggregates crossing any specific link, but the aggregation assumption is that a link not showing any marking can't be driven into overload by addition of a single flow. Imagine now a path between two edge nodes that crosses one link shared by 2 aggregates (a possible figure in BT's core) and another shared by 1000 aggregates (a typical figure across BT's core). How meaningful would it be for the second link to say to 1000 aggregates that 20M is available? Or for the first link to say to both aggregates that 500k is available? How meaningful would it be for either link to say there is 1% pre-congestion? In any of these cases, the numbers are fairly meaningless because the edge nodes don't know how many other edge nodes they are up against. This uncertainty is a design 'feature' of a distributed solution like PCN - because it's hard to know which situation you're in without a system-wide view (and we eventually want system-wide to mean Internet-wide): - am I the only one asking? - am I part of a flash crowd? - am I part of normal flow arrivals and departures? - what is normal anyway? So, for admission control, I think the important thing about the marking is its shape wrt load. It should rise gradually then get steeper as the reference rate is approached and rapidly saturate at some point (the reference rate). Then edge nodes can set their thresholds somewhere between the two, so they trigger admission control close to the reference rate, but sufficiently under the reference rate to give contingency if they happen to be part of a flash crowd. I also believe it is useful for the marking to be dimensionless (ie a fraction rather than meaning a certain rate). Then the system scales into the future as rates increase by orders of magnitude. Bob At 08:08 24/08/2007, Geib, Ruediger wrote: >Lachlan, Bob, > >you both seem to agree that ramp marking is the best solution. >Picking up Lachlan's pretty sound arguments on different thresholds >for different types of incoming calls - what you describe is >estimating the available (not consumed) PCN bandwidth rather than >just a "pre congestion notification", I think. >If there's a simple solution to realise this idea, PCN should >investigate it. This could be helpful if there's a new call to be >admitted and no PCN flow exists between two gateways. The question >then would be, whether a certain bandwidth is available, rather >than "any congestion visible". > >Regards, > >Ruediger > > >|Lachlan wrote: >|I believe that the marking scheme should carry as much information as >|possible about the network state, and that thresholding should be done >|as late as possible (at the decision-making end-points). The more >|information the decision-making entity has, better the decisions it >|can make. >| >|If things like thresholding are done where the admission decisions are >|made, there is also a smoother upgrade path for changes in the >|admission rules. For example, an operator may want to apply different >|thresholds applied to different types of incoming calls. If routers >|provide a single threshold, this can't be implemented at a later >|stage. Similarly, an operator may want to admit a certain percentage >|of traffic dependent on the congestion level, rather than admitting >|all or none. > >|Bob wrote: >|[BB] The problem we were trying to solve with ramp marking was the >|reverse: >|we were looking for a marking algo that produced a smooth increase in >|marking over a wider range of loads. The edge nodes can always turn a >|smooth rise into a toggle at a specific threshold marking level. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 29 04:58:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJNe-0003mP-BJ; Wed, 29 Aug 2007 04:58:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQJNd-0003mK-UM for pcn-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 04:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJNd-0003mC-KB for pcn@ietf.org; Wed, 29 Aug 2007 04:58:29 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQJNc-0000so-2Q for pcn@ietf.org; Wed, 29 Aug 2007 04:58:29 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 29 Aug 2007 10:58:25 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Aug 2007 10:58:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: [PCN] RE: ECN & EF Date: Wed, 29 Aug 2007 10:58:24 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB9B01@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECN & EF thread-index: AcfmmutUuJa7E4aQScGJrj/D0+aK0ADcgBxAAAIvToA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 29 Aug 2007 08:58:25.0073 (UTC) FILETIME=[C226F210:01C7EA1A] X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, my comment in line, marked [Rudi] Regards, Ruediger > Steven wrote [Chair hat off] >=20 > Philip et. al., [snip] > - EF PHB is assumed for all PCN-managed traffic. [snip] =20 [This] > might or might not be a sensible idea in most circumstances,=20 > but I cannot think of a rationale as to why it is required. So I=20 > suggest that you also come up with a rationale for > this assumption, or weaken the statement in the draft. [Phil] It's basically Assumption 2 (Section 3.2), "We assume that PCN-packets come from real time applications generating inelastic traffic [Shenker] like voice and video requiring low delay, jitter and packet loss, for example the Controlled Load Service, [RFC2211], and the Telephony service class, [RFC4594]." I don't think the EF PHB is intended to say anything different (is that true?), although you could argue they're not the same.=20 [Rudi]: We should mention that explicitely. [Phil] The justification in S3.2 says: "This assumption is to help focus the effort where it looks like PCN would be most useful, ie the sorts of applications where per flow QoS is a known requirement." this is true, although personally I think there's more to it than that - we don't really understand how the 'Many flows' assumption (Section 3.3) works for rate adaptive traffic. Compared with VBR traffic, rate adaptive tends to have much coarser changes of rate (bigger jumps, sticks at new rate for longer time), which probably makes it harder to get nicely behaving aggregated traffic. The other thing for rate adaptive traffic is to imagine if the PCN-domain is the part of the end-to-end path with the bandwidth constraint. One could imagine after flows had been admitted that the rates start adapting upwards. There would be no pkt drops to trigger the sources to adapt their rates downwards, and so flow termination would eventually kick in. I think the safety margins you'd need to allow would be greater than for VBR sources. However, we haven't (as far as I know) investigated how much harder rate adaptive sources would be for PCN than VBR ones (whether you just have to be more cautious and allow bigger safety margins, or whether it doesn't really work). Hence the assumption in S3.2. [Rudi] There've been "real time applications generating inelastic traffic",=20 "EF" and here you discuss "VBR traffic" and "rate adaptive traffic".=20 You don't mention PCN traffic which isn't using EF. Do you assume "VBR=20 traffic" and "rate adaptive traffic" to use other PHBs than EF?=20 We should write down the assumptions which seem to be there on the=20 PCN traffic and its management. I can imagine - Voice traffic to use other PHBs than EF. - Broadcast and Unicast traffic with CBR like charactersitics to=20 use non-EF PHBs. Both may be good candidates candidates for PCN.=20 I further don't have trouble with VBR sources. If every single VBR=20 source's rate is far below the rate of the aggregate of many VBR=20 sources and these VBR sources are statistically independant, then=20 PCN should be able to operate smoothely on such an aggregate, which=20 probably exposes CBR like properties. [Phil] So my suggestion would be to keep the statement about EF PHB but add a reference to S3.2 and say something like "it isn't intended to be saying anything different to this" Comments? =20 >=20 >=20 > Regards, >=20 > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 29 05:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJls-0006AY-T9; Wed, 29 Aug 2007 05:23:32 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQJlr-000698-K1 for pcn-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 05:23:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJlq-00067G-VB for pcn@ietf.org; Wed, 29 Aug 2007 05:23:31 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQJlp-00026D-Sf for pcn@ietf.org; Wed, 29 Aug 2007 05:23:30 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 29 Aug 2007 11:23:28 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Aug 2007 11:23:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Date: Wed, 29 Aug 2007 11:23:27 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB9B02@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking thread-index: AcfqGnpHu1p7/Gj6RVKVGfU66v+KxQAAX7WA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 29 Aug 2007 09:23:27.0845 (UTC) FILETIME=[41DFC150:01C7EA1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: pcn@ietf.org, l.andrew@ieee.org, eeschan@cityu.edu.hk X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Bob, thanks for the explanation. I didn't consider the "race condition"=20 resulting from different ingress/egress aggregates competing for=20 the same available bandwidth on a link yet. Your point is very good. I came to conclude that differing link bandwidths wouldn't simplify measuring QoS resources available or consumed in absolute terms.=20 Your last point on dimensionless marking is a good one too. Regards, Ruediger=20 -----Original Message----- From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] Sent: Wednesday, August 29, 2007 10:55 AM To: Geib, Rudiger Cc: l.andrew@ieee.org; pcn@ietf.org; eeschan@cityu.edu.hk Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking Ruediger, I was preparing an answer to both you & Joe yesterday, but the one to Joe=20 needs to be a bit more involved, so below is my response to your point, and=20 I'll get back to Joe next... Pre-congestion notification is a form of estimating available bandwidth for=20 the Diffserv class - they aren't mutually exclusive. I'll explain using an=20 example of three aggregates crossing a link: a) option | b) option ____________________________|___________________________________________ ___ load from available | percent PCN marking share of ingress capacity | PCN threshold available | (constant) capacity | 3.0M __ __ 495k | 6% 15% (15%-6%)x3.0M =3D = 270k \ / | 2.0M ---+----+--- 495k | 6% 15% (15%-6%)x2.0M =3D = 180k __/ \__ | 500k 495k | 6% 15% (15%-6%)x500k =3D = 45k ____ Total available capacity =3D = 495k You get the same answer both ways but neither is meaningful. The question=20 is, which is better: a) telling all edge nodes 495k is available (even tho no more than one can=20 use any part of it at a time)? or b) telling all edge nodes they can each send 9% (=3D15%-6%) more than = they are currently sending (when they are all unlikely to do so at the same time=20 but they might)? In both cases, no single edge node knows how much extra traffic it can send=20 because it doesn't know how many other nodes might be about to do the same: a) each node should not add 495k in case others do too b) each node will probably think it can add more than its share of=20 available capacity, because not all other nodes are likely to in the next=20 round trip time. In practice there may be anything from 0 to 10,000s of aggregates crossing=20 any specific link, but the aggregation assumption is that a link not=20 showing any marking can't be driven into overload by addition of a single flow. Imagine now a path between two edge nodes that crosses one link shared by 2=20 aggregates (a possible figure in BT's core) and another shared by 1000=20 aggregates (a typical figure across BT's core). How meaningful would it be=20 for the second link to say to 1000 aggregates that 20M is available? Or for=20 the first link to say to both aggregates that 500k is available? How=20 meaningful would it be for either link to say there is 1% pre-congestion?=20 In any of these cases, the numbers are fairly meaningless because the edge=20 nodes don't know how many other edge nodes they are up against. This uncertainty is a design 'feature' of a distributed solution like PCN -=20 because it's hard to know which situation you're in without a system-wide=20 view (and we eventually want system-wide to mean Internet-wide): - am I the only one asking? - am I part of a flash crowd? - am I part of normal flow arrivals and departures? - what is normal anyway? So, for admission control, I think the important thing about the marking is=20 its shape wrt load. It should rise gradually then get steeper as the=20 reference rate is approached and rapidly saturate at some point (the=20 reference rate). Then edge nodes can set their thresholds somewhere between=20 the two, so they trigger admission control close to the reference rate, but=20 sufficiently under the reference rate to give contingency if they happen to=20 be part of a flash crowd. I also believe it is useful for the marking to be dimensionless (ie a=20 fraction rather than meaning a certain rate). Then the system scales into=20 the future as rates increase by orders of magnitude. Bob At 08:08 24/08/2007, Geib, Ruediger wrote: >Lachlan, Bob, > >you both seem to agree that ramp marking is the best solution. >Picking up Lachlan's pretty sound arguments on different thresholds >for different types of incoming calls - what you describe is >estimating the available (not consumed) PCN bandwidth rather than >just a "pre congestion notification", I think. >If there's a simple solution to realise this idea, PCN should >investigate it. This could be helpful if there's a new call to be >admitted and no PCN flow exists between two gateways. The question >then would be, whether a certain bandwidth is available, rather >than "any congestion visible". > >Regards, > >Ruediger > > >|Lachlan wrote: >|I believe that the marking scheme should carry as much information as >|possible about the network state, and that thresholding should be done >|as late as possible (at the decision-making end-points). The more >|information the decision-making entity has, better the decisions it >|can make. >| >|If things like thresholding are done where the admission decisions are >|made, there is also a smoother upgrade path for changes in the >|admission rules. For example, an operator may want to apply different >|thresholds applied to different types of incoming calls. If routers >|provide a single threshold, this can't be implemented at a later >|stage. Similarly, an operator may want to admit a certain percentage >|of traffic dependent on the congestion level, rather than admitting >|all or none. > >|Bob wrote: >|[BB] The problem we were trying to solve with ramp marking was the >|reverse: >|we were looking for a marking algo that produced a smooth increase in >|marking over a wider range of loads. The edge nodes can always turn a >|smooth rise into a toggle at a specific threshold marking level. ________________________________________________________________________ ____ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 29 15:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQT6G-0007hO-IG; Wed, 29 Aug 2007 15:21:12 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQT69-0007g9-Cd for pcn-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 15:21:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQT66-0007ed-CM for pcn@ietf.org; Wed, 29 Aug 2007 15:21:04 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQT65-0006GR-Im for pcn@ietf.org; Wed, 29 Aug 2007 15:21:02 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7TJKvkg012636; Wed, 29 Aug 2007 15:20:57 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7TJKN2m016796; Wed, 29 Aug 2007 15:20:55 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 15:20:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] RE: ECN & EF Date: Wed, 29 Aug 2007 15:20:42 -0400 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC443@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] RE: ECN & EF Thread-Index: AcfmmutUuJa7E4aQScGJrj/D0+aK0ADcgBxAABkRB5A= References: <1187993140.1512.124.camel@neutrino> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC443@E03MVZ1-UKDY.domain1.systemhost.net> To: X-OriginalArrivalTime: 29 Aug 2007 19:20:43.0522 (UTC) FILETIME=[B19A1E20:01C7EA71] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -3, SUBJ_ALL_CAPS! .5, NO_REAL_NAME 0, __C230066_P5 0, __CP_MEDIA_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.8 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, EF PHB has the right properties for this traffic, but it's not the only way to get them. I think the decision on the table is: a) It has to be the EF PHB, vs. b) It has to be similar to the EF PHB, but need not be exactly the EF PHB. For the latter, over-provisioned AF may be another way to do this. I don't have a strong opinion on which alternative we choose, but one of them does have to be chosen. Thanks, --David > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: Wednesday, August 29, 2007 3:45 AM > To: steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: [PCN] RE: ECN & EF >=20 > Steven, =20 > Thanks - my perspective is in-line > phil >=20 > > -----Original Message----- > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > Sent: 24 August 2007 23:06 > > To: Eardley,PL,Philip,CXR9 R > > Cc: pcn@ietf.org > > Subject: ECN & EF > >=20 > > [Chair hat off] > >=20 > > Philip et. al., > >=20 > > I see that in Sec. 3.5 of the architecture draft, you assume: > >=20 > > - Packets with ECN CE markings arriving at a PCN ingress router > > are automatically dropped. > >=20 > > - EF PHB is assumed for all PCN-managed traffic. > >=20 > > I asked previously if we needed to make the first=20 > assumption when ECN > > header bits are NOT being used to signal PCN markings. As=20 > far as I know > > the answer is no. So I would suggest you either (a) write up a > > rationale for assuming this, or (b) mention that it is only an issue > > when re-using the ECN bits for PCN marking (which we haven't decided > > yet). >=20 > Yes, I think your option b) is true. I'll modify this section=20 > to say this. >=20 > >=20 > > Regarding the second assumption, it might or might not be a sensible > > idea in most circumstances, but I cannot think of a=20 > rationale as to why > > it is required. So I suggest that you also come up with a=20 > rationale for > > this assumption, or weaken the statement in the draft. >=20 > It's basically Assumption 2 (Section 3.2), "We assume that PCN-packets > come from real time applications > generating inelastic traffic [Shenker] like voice and=20 > video requiring > low delay, jitter and packet loss, for example the Controlled Load > Service, [RFC2211], and the Telephony service class, [RFC4594]." >=20 > I don't think the EF PHB is intended to say anything=20 > different (is that > true?), although you could argue they're not the same.=20 >=20 > The justification in S3.2 says: "This > assumption is to help focus the effort where it looks like=20 > PCN would > be most useful, ie the sorts of applications where per=20 > flow QoS is a > known requirement." >=20 > this is true, although personally I think there's more to it=20 > than that - > we don't really understand how the 'Many flows' assumption=20 > (Section 3.3) > works for rate adaptive traffic. Compared with VBR traffic, rate > adaptive tends to have much coarser changes of rate (bigger jumps, > sticks at new rate for longer time), which probably makes it harder to > get nicely behaving aggregated traffic. The other thing for rate > adaptive traffic is to imagine if the PCN-domain is the part of the > end-to-end path with the bandwidth constraint. One could imagine after > flows had been admitted that the rates start adapting upwards. There > would be no pkt drops to trigger the sources to adapt their rates > downwards, and so flow termination would eventually kick in.=20 > I think the > safety margins you'd need to allow would be greater than for VBR > sources. However, we haven't (as far as I know) investigated how much > harder rate adaptive sources would be for PCN than VBR ones=20 > (whether you > just have to be more cautious and allow bigger safety margins, or > whether it doesn't really work). Hence the assumption in S3.2. >=20 > So my suggestion would be to keep the statement about EF PHB but add a > reference to S3.2 and say something like "it isn't intended=20 > to be saying > anything different to this" >=20 > Comments? > =20 >=20 > >=20 > >=20 > > Regards, > >=20 > > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 29 15:42:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTQh-0008Vj-4j; Wed, 29 Aug 2007 15:42:19 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQTQd-0008VY-0a for pcn-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 15:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTQa-0008Un-AZ for pcn@ietf.org; Wed, 29 Aug 2007 15:42:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQTQY-00053l-Rp for pcn@ietf.org; Wed, 29 Aug 2007 15:42:12 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Aug 2007 12:42:10 -0700 X-IronPort-AV: i="4.19,323,1183359600"; d="scan'208"; a="518485072:sNHT57666650" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7TJgAIe005031; Wed, 29 Aug 2007 12:42:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7TJgAxl024548; Wed, 29 Aug 2007 19:42:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 12:42:09 -0700 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 12:42:09 -0700 In-Reply-To: References: <1187993140.1512.124.camel@neutrino> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC443@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [PCN] RE: ECN & EF Date: Wed, 29 Aug 2007 12:42:07 -0700 To: Black_David@emc.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Aug 2007 19:42:09.0737 (UTC) FILETIME=[B03EF390:01C7EA74] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5736; t=1188416530; x=1189280530; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20RE=3A=20ECN=20&=20EF |Sender:=20; bh=2bd7NGWLEcvR3yS1j9hlRd/XUR0i81IJNBH/GeFveyg=; b=fLrSTuiaoy0Ck8nPD0JbSjAWGjao6hdiodMMq4ZfvEpnFUVVb2sOO8UN6e3+mKEb0NWq+16r ewxVgQhNZlccZwTu8lkfv2BIlSc+JSrVqOxWDLfnGbnaLYM6701EVszo; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org AF is proposed for video because video has variable traffic and one might want to mark frames of lower delivery importance with a higher drop probability. Think layered codecs and the difference between I frames and other types of frames. That said, I would be hard pressed to recommend it for voice unless the other characteristics were such that the math in RFC 3247 was supported. What PHB one uses is all about what the characteristics of the intended applications are. I would be pretty hesitant to use PCN in an environment where you couldn't run an entire session and perhaps several in the margin zone - if suddenly adding 10% more sessions simultaneously when things are at the edge is going to disrupt existing sessions, the margins are too tight. For that reason, I think part of this discussion has got to be "for what application" and the testing has to include testing it with that application in live environments. On Aug 29, 2007, at 12:20 PM, Black_David@emc.com wrote: > Phil, > > EF PHB has the right properties for this traffic, but it's not the > only way to get them. I think the decision on the table is: > a) It has to be the EF PHB, vs. > b) It has to be similar to the EF PHB, but need not be > exactly the EF PHB. > For the latter, over-provisioned AF may be another way to do this. > > I don't have a strong opinion on which alternative we choose, but > one of them does have to be chosen. > > Thanks, > --David > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: Wednesday, August 29, 2007 3:45 AM >> To: steven.blake@ericsson.com >> Cc: pcn@ietf.org >> Subject: [PCN] RE: ECN & EF >> >> Steven, >> Thanks - my perspective is in-line >> phil >> >>> -----Original Message----- >>> From: Steven Blake [mailto:steven.blake@ericsson.com] >>> Sent: 24 August 2007 23:06 >>> To: Eardley,PL,Philip,CXR9 R >>> Cc: pcn@ietf.org >>> Subject: ECN & EF >>> >>> [Chair hat off] >>> >>> Philip et. al., >>> >>> I see that in Sec. 3.5 of the architecture draft, you assume: >>> >>> - Packets with ECN CE markings arriving at a PCN ingress router >>> are automatically dropped. >>> >>> - EF PHB is assumed for all PCN-managed traffic. >>> >>> I asked previously if we needed to make the first >> assumption when ECN >>> header bits are NOT being used to signal PCN markings. As >> far as I know >>> the answer is no. So I would suggest you either (a) write up a >>> rationale for assuming this, or (b) mention that it is only an issue >>> when re-using the ECN bits for PCN marking (which we haven't decided >>> yet). >> >> Yes, I think your option b) is true. I'll modify this section >> to say this. >> >>> >>> Regarding the second assumption, it might or might not be a sensible >>> idea in most circumstances, but I cannot think of a >> rationale as to why >>> it is required. So I suggest that you also come up with a >> rationale for >>> this assumption, or weaken the statement in the draft. >> >> It's basically Assumption 2 (Section 3.2), "We assume that PCN- >> packets >> come from real time applications >> generating inelastic traffic [Shenker] like voice and >> video requiring >> low delay, jitter and packet loss, for example the Controlled Load >> Service, [RFC2211], and the Telephony service class, [RFC4594]." >> >> I don't think the EF PHB is intended to say anything >> different (is that >> true?), although you could argue they're not the same. >> >> The justification in S3.2 says: "This >> assumption is to help focus the effort where it looks like >> PCN would >> be most useful, ie the sorts of applications where per >> flow QoS is a >> known requirement." >> >> this is true, although personally I think there's more to it >> than that - >> we don't really understand how the 'Many flows' assumption >> (Section 3.3) >> works for rate adaptive traffic. Compared with VBR traffic, rate >> adaptive tends to have much coarser changes of rate (bigger jumps, >> sticks at new rate for longer time), which probably makes it >> harder to >> get nicely behaving aggregated traffic. The other thing for rate >> adaptive traffic is to imagine if the PCN-domain is the part of the >> end-to-end path with the bandwidth constraint. One could imagine >> after >> flows had been admitted that the rates start adapting upwards. There >> would be no pkt drops to trigger the sources to adapt their rates >> downwards, and so flow termination would eventually kick in. >> I think the >> safety margins you'd need to allow would be greater than for VBR >> sources. However, we haven't (as far as I know) investigated how much >> harder rate adaptive sources would be for PCN than VBR ones >> (whether you >> just have to be more cautious and allow bigger safety margins, or >> whether it doesn't really work). Hence the assumption in S3.2. >> >> So my suggestion would be to keep the statement about EF PHB but >> add a >> reference to S3.2 and say something like "it isn't intended >> to be saying >> anything different to this" >> >> Comments? >> >> >>> >>> >>> Regards, >>> >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Steven Blake >>> Ericsson/Redback Networks +1 919-472-9913 >> >> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> >> > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 29 15:57:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTfa-0006IB-Ol; Wed, 29 Aug 2007 15:57:44 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQTfK-00061h-Td for pcn-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 15:57:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTfK-0005yY-E4 for pcn@ietf.org; Wed, 29 Aug 2007 15:57:26 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQTfK-00088i-1O for pcn@ietf.org; Wed, 29 Aug 2007 15:57:26 -0400 Received: from [192.168.1.2] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (alnrmhc16) with SMTP id <20070829195724b1600ql968e>; Wed, 29 Aug 2007 19:57:25 +0000 In-Reply-To: References: <1187993140.1512.124.camel@neutrino> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC443@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24F6F524-434F-4366-9136-AC8B1353DD3F@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] RE: ECN & EF Date: Wed, 29 Aug 2007 15:57:22 -0400 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > AF is proposed for video because video has variable traffic and one > might want to mark frames of lower delivery importance with a > higher drop probability. Think layered codecs and the difference > between I frames and other types of frames. That said, I would be > hard pressed to recommend it for voice unless the other > characteristics were such that the math in RFC 3247 was supported. one possibility would be for audio streams that use transport layer FEC, and to mark the FEC packets with lower drop probability since they are built to reconstruct other lost data packets. -ken > What PHB one uses is all about what the characteristics of the > intended applications are. I would be pretty hesitant to use PCN in > an environment where you couldn't run an entire session and perhaps > several in the margin zone - if suddenly adding 10% more sessions > simultaneously when things are at the edge is going to disrupt > existing sessions, the margins are too tight. For that reason, I > think part of this discussion has got to be "for what application" > and the testing has to include testing it with that application in > live environments. agreed, that would be nice to see. And just a side comment, my understanding is that folks are thinking more in terms of changing conditions that suddenly add significantly more than 10%. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 30 04:11:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQf7x-0007Jo-SH; Thu, 30 Aug 2007 04:11:45 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQf7w-0007JU-8M for pcn-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 04:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQf7s-0007Ig-8e for pcn@ietf.org; Thu, 30 Aug 2007 04:11:40 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQf7q-0002w4-PE for pcn@ietf.org; Thu, 30 Aug 2007 04:11:40 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 09:11:37 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 09:11:36 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1188461495678; Thu, 30 Aug 2007 09:11:35 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.119]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7U8BNc9020682; Thu, 30 Aug 2007 09:11:35 +0100 Message-Id: <5.2.1.1.2.20070830085617.03efed38@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 30 Aug 2007 09:11:17 +0100 To: "Jozef Babiarz" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Aug 2007 08:11:36.0728 (UTC) FILETIME=[62A94180:01C7EADD] X-Spam-Score: -1.0 (-) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: pcn@ietf.org Subject: [PCN] draft-babiarz-pcn-3sm-00 pseudocode nit X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, In the admission marking pseudo-code in draft-babiarz-pcn-3sm-00 S.2.2.2, if a packet arrives that is larger than the current depth of the token bucket, you correctly mark the packet with admission stop marking, but I think you've omitted to empty the bucket to zero as well. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ if (TB.fill < packet.size) TB.fill = 0; // BB: Suggested amendment packet.mark = AS; else TB.fill = TB.fill - packet.size; if (TB.fill < TB.threshold) packet.mark = AS; endif endif /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 30 13:17:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQndx-00046H-1t; Thu, 30 Aug 2007 13:17:21 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQndw-00046C-0z for pcn-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 13:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQndv-00045y-Lt for pcn@ietf.org; Thu, 30 Aug 2007 13:17:19 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQndt-000269-Ko for pcn@ietf.org; Thu, 30 Aug 2007 13:17:19 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 18:17:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture new section on tunnelling Date: Thu, 30 Aug 2007 18:17:15 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC45E@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture new section on tunnelling Thread-Index: AcfaCXJksAu35/rvTceRV0cJc3CgAwEkoZpgAMp4jqACWNwFsA== From: To: , X-OriginalArrivalTime: 30 Aug 2007 17:17:16.0439 (UTC) FILETIME=[9D0CB270:01C7EB29] X-Spam-Score: -1.0 (-) X-Scan-Signature: d119718c9ef593f359a025ee0d2770e1 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1765671301==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1765671301== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EB29.9CC1E691" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EB29.9CC1E691 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks - I'll add some explanation to the draft. Also in the next version of the draft I'll add a note that the RFCs you mention should be explored in more detail [unless of course someone does this exploration before then] =20 phil =20 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: 18 August 2007 19:38 To: babiarz@nortel.com; pcn@ietf.org Subject: RE: [PCN] PCN architecture new section on tunnelling =20 Joe, =20 * any PCN-marking is copied into the outer header [Joe] The above may introduce unnecessary information leakage. Why not just at the encapsulation point mark all packets as unmarked. The decapsulation point can sort them out. Just realizes that excess rate marking approach will not work unless PCN-marking information is copied from inner to outer headers when encapsulating. [end] =20 [DLB] The copying can simplify dealing with the various headers. If the PCN marking is always in the outermost header (copied out on ingress, copied in on egress), then dealing with PCN marking is orthogonal to tunnel encap/ decap, and in particular, the right thing happens if a tunnel crosses a PCN boundary and has its egress in the middle of a PCN domain. This is related to RFC 2983's uniform model for dealing with diffserv and tunnels, and some of the tunnel discussion in RFC 3270 (MPLS and diffserv) mayalso be useful to review (not because MPLS and PCN ought to be in scope, but rather because Francois and the RFC 3270 co-authors did a fine jobof exploring the implications of the uniform and pipe models in RFC 3270 to the next levels of detail. =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 =20 =09 ________________________________ From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: Tuesday, August 14, 2007 2:17 PM To: philip.eardley@bt.com; pcn@ietf.org Subject: RE: [PCN] PCN architecture new section on tunnelling Phil, please see my comment below demarked with [Joe]. =20 Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: August 8, 2007 6:14 PM To: pcn@ietf.org Subject: [PCN] PCN architecture new section on tunnelling =20 This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about tunelling: =20 5.8. Tunnelling =20 It is possible that tunnels terminate at a PCN-node. It is important that any PCN-marking is preserved after decapsulation, so that it is still seen by the PCN-egress-node. To ensure this, on decapsulation the following rules are applied: =20 o the PCN-marking state of the inner and outer headers are compared =20 o if the inner header's marking state is more severe then it is preserved =20 o if the outer header's marking state is more severe then it is copied onto the inner header =20 o NB the order of increasing severity is: unmarked; PCN-marking with first encoding (ie associated with the PCN-lower-rate); PCN- marking with second encoding (ie associated with the PCN-upper- rate) =20 Similarly, if encapsulation is done within the PCN-domain, then the following rule is applied: =20 * any PCN-marking is copied into the outer header [Joe] The above may introduce unnecessary information leakage. Why not just at the encapsulation point mark all packets as unmarked. The decapsulation point can sort them out. Just realizes that excess rate marking approach will not work unless PCN-marking information is copied from inner to outer headers when encapsulating. [end] =20 [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN nonce) is out of scope as we are not sure if it's need for PCN. If not than the "PCN nonce" would also need to be copied to outer header. [end]=20 =20 Tunnelling considerations also depend on which header bits the PCN WG decides to use. If the ECN bits are used then [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to its spirit. If the DSCP field is used then [RFC2983] needs to be considered carefully. =20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes, in which case the rules above aren't needed. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow; even if ECMP is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path. But it also has drawbacks: additional overhead in terms of bandwidth and processing; and the effective elimination of ECMP as a load balancing mechanism. =20 =20 ------_=_NextPart_001_01C7EB29.9CC1E691 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Thanks – I’ll add some explanation to the draft.

Also in the next version of the = draft I’ll add a note that the RFCs you mention should be explored in more detail = [unless of course someone does this exploration before then]

 

phil

 

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: 18 August 2007 = 19:38
To: babiarz@nortel.com; pcn@ietf.org
Subject: RE: [PCN] PCN architecture new section on tunnelling

 

Joe,

 

·         any PCN-marking is copied into the outer header

[Joe] The above may introduce = unnecessary information leakage. Why not just at the encapsulation point mark all = packets as unmarked. The decapsulation point can sort them out. Just realizes = that excess rate marking approach will not work unless PCN-marking = information is copied from inner to outer headers when encapsulating. = [end]

 

[DLB] The copying can simplify dealing with the various headers. If the

PCN marking is always in the = outermost header (copied out on ingress, copied

in on egress), then dealing with = PCN marking is orthogonal to tunnel encap/

decap, and in particular, the = right thing happens if a tunnel crosses a PCN

boundary and has its egress in = the middle of a PCN domain. This is related

to RFC 2983's uniform model for = dealing with diffserv and tunnels, and some

of the tunnel discussion in RFC = 3270 (MPLS and diffserv) mayalso be useful

to review (not because MPLS and = PCN ought to be in scope, but rather because

Francois and the RFC 3270 = co-authors did a fine jobof exploring the

implications of the uniform and = pipe models in RFC 3270 to the next levels

of detail.

 

Thanks,

--David

-----------------------------------= -----------------
David = L. Black, Senior Technologist
EMC = Corporation, 176 South St., Hopkinton, MA 01748
+1 = (508) 293-7953           = ;  FAX: +1 (508) 293-7786
black_david@emc.com     &nb= sp;  Mobile: +1 (978) 394-7754
----------------------------------------------------=

 

From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: Tuesday, August 14, = 2007 2:17 PM
To: = philip.eardley@bt.com; pcn@ietf.org
Subject: RE: [PCN] PCN architecture new section on tunnelling

Phil, please see = my comment below demarked with [Joe].

 

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

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: August 8, 2007 6:14 = PM
To: pcn@ietf.org
Subject: [PCN] PCN = architecture new section on tunnelling

 

This is to flag up that I wrote a new = sub-section (in Section 5, Detailed functional architecture) about = tunelling:

 

5.8.  Tunnelling

 

   It is possible that tunnels terminate at a = PCN-node.  It is important

   that any PCN-marking is preserved after = decapsulation, so that it is

   still seen by the PCN-egress-node.  To ensure = this, on decapsulation

   the following rules are applied:

 

   o  the PCN-marking state of the inner and = outer headers are compared

 

   o  if the inner header's marking state is more = severe then it is

      preserved

 

   o  if the outer header's marking state is more = severe then it is

      copied onto the inner = header

 

   o  NB the order of increasing severity is: = unmarked; PCN-marking with

      first encoding (ie associated = with the PCN-lower-rate); PCN-

      marking with second encoding (ie associated with the PCN-upper-

      rate)

 

   Similarly, if encapsulation is done within the = PCN-domain, then the

   following rule is applied:

 

·         any PCN-marking is copied into the outer header

[Joe] The above may introduce = unnecessary information leakage. Why not just at the encapsulation point mark all = packets as unmarked. The decapsulation point can sort them out. Just realizes = that excess rate marking approach will not work unless PCN-marking = information is copied from inner to outer headers when encapsulating. = [end]

 

[Joe] I’m assuming for time = being that “PCN nonce” (similar to ECN nonce) is out of scope as = we are not sure if it’s need for PCN. If not than the “PCN = nonce” would also need to be copied to outer header. [end]

 

   Tunnelling considerations also depend on which = header bits the PCN WG

   decides to use.  If the ECN bits are used = then

   [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules = above conform to

   its spirit.  If the DSCP field is used then = [RFC2983] needs to be

   considered carefully.

 

   An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to

   PCN-egress-nodes, in which case the rules above = aren't needed.  The

   potential reasons for doing such tunnelling are: = the PCN-egress-node

   then automatically knows the address of the = relevant PCN-ingress-node

   for a flow; even if ECMP is running, all = PCN-packets on a particular

   ingress-egress-aggregate follow the same = path.  But it also has

   drawbacks: additional overhead in terms of = bandwidth and processing;

   and the effective elimination of ECMP as a load = balancing mechanism.

 

 

=00 ------_=_NextPart_001_01C7EB29.9CC1E691-- --===============1765671301== 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://www1.ietf.org/mailman/listinfo/pcn --===============1765671301==-- From pcn-bounces@ietf.org Thu Aug 30 15:09:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQpOk-0007JM-KI; Thu, 30 Aug 2007 15:09:46 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQpOj-0007Hc-TR for pcn-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 15:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQpOj-0007HU-Jj for pcn@ietf.org; Thu, 30 Aug 2007 15:09:45 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQpOi-0004m2-4K for pcn@ietf.org; Thu, 30 Aug 2007 15:09:45 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7UJ9fi07717; Thu, 30 Aug 2007 19:09:41 GMT Received: from KCHAN-2K3.nortel.com ([47.16.54.136] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:09:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 30 Aug 2007 15:09:32 -0400 To: From: "Kwok-Ho Chan" Subject: RE: [PCN] Consensus call: movingdraft-chan-pcn-encoding-comparison-00 to working group document In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3D6@E03MVZ1-UKDY.doma in1.systemhost.net> References: <2CCC0BFE-6DDF-4027-836E-0816484667DB@cisco.com> <75A199C5D243C741BF3D3F1EBCEF9BA5019DC3D6@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 30 Aug 2007 19:09:32.0853 (UTC) FILETIME=[4C43E650:01C7EB39] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, Bruce, all: Thank you very much for the suggestions. They are inline with the direction I was heading on simplifying the original pre-00 draft. With the received support on continuing the simplification direction. I am currently rewriting most of the draft. Removing much of the extras. Thanks! -- Kwok -- At 11:31 AM 8/14/2007, philip.eardley@bt.com wrote: >I thought about this more (101 uses for boring meetings). > >For the I-D I suggest: >Part A: lists the encodings >Part B: discusses pros and cons of them > >Part A, I entirely agree with the approach that Bruce suggests below, ie >draft just says various approaches require 2, 3 (& 4?) codepoints >(PCN-marked, unmarked; etc), and for each then list encoding options >(DSCP-1, DSCP-2 OR ECN-'11', ECN-'00'; etc). I'd stick here to simply >how many codepoints the PCN mechanism itself requires; there are some >specific encodings that actually under a given set of scenario >assumptions need more codepoints, but I'd deal with that under Part B as >a disadvantage. > > >Part B >I think this nicely divides into 'issues for encodings that use dscp >field' and 'issues for encodings that use ecn field'. Encodings that use >both get both sets of issues [if it's more complicated than that, >consider later in detail, basically a second order issue] > >For encodings that uses DSCP field: >1. interactions with multiple PCN classes. Ie if there are n PCN >classes, you need n times as many codepoints (=dscps). Because PCN-nodes >use DSCPs to distinguish PCN classes. This is a particular issue for >operating PCN in an MPLS network, where you have less codepoint space >(same argument probably applies to PCN on other networks eg Ethernet?). >one option is simply to insist that there's only 1 pcn class (nb not >what the architecture draft says). >2. interactions with ECMP. ECMP algos can use a packet's DSCP when >deciding what interface to fwd it on. In a PCN-domain running ECMP, for >a flow which has some packets PCN-marked and some unmarked. its packets >will travel over more than one path. This may well lead to mis-ordering. >ug. Maybe some more complicated interactions, esp if there are multiple >pre-congested nodes... not sure. >3. maybe something about dscps being quite lightly standardised - >limited rules on how you use them, largely up to the operator. >4. interactions with RFC4794 use of ecn field. None. > >For encodings that use ECN field: >1. interactions with ECMP. None. ECMP algos don't use a packet's ECN >field when deciding what interface to fwd it on >2. interactions with multiple PCN classes. None. Doesn't change the >number of codepoints needed. > >in the bullets below, '(un)planned' isn't quite the right word. I'm >trying to distinguish between cases where everything is behaving >correctly and cases where something is misconfigured or something else >has gone wrong. >3. 'planned' interactions with CE (ie a pkt arrives, in a PCN class, at >PCN-ingress-node with CE). The architecture draft (S3.5) has some text >on how this is handled (basically, the default option is just to drop >the pkt). >4. 'planned' interactions with ECT (ie a pkt arrives at PCN-ingress-node >with ECT-1 or ECT-0). Probably best to forward the pkt (effectively >re-set to '00'), or else drop as per CE pkts? >5. 'unplanned' interactions with ECN. These are some of the things said >or suggested in [RFC4774], I think the 3 main categories are: >- a RFC4774 pkt gets accidentally dscp-re-marked to the pcn-dscp; a >PCN-ingress-node gets misconfigured so it allows a RFC4774 pkt in on the >pcn-dscp. Can anything nasty happen? >- a router in the PCN-domain misconfigures itself so it's >RFC3246-enabled (ie no longer PCN-enabled). Can anything nasty happen, >eg when PCN-marked pkts encounter this router? >- a PCN-egress-node gets misconfigured so it allows a pcn-marked pkt >'out' of the PCN-domain. >this section is a bit trickier to think about; it needs a short para on >each possible misconfiguration scenario to explain what the (potential) >issue is; they're definitely not equally important. Also, we should make >sure the discussion is confined to ecn-pcn interactions (I have a >feeling it would be easy to get side-tracked into wider misconfiguration >issues that have nothing to do with encoding choice) > > >there are a few very detailed issues (eg in S11.6.4 & 11.6.5 of >draft-briscoe-tsvwg-cl-phb-03, but we can ignore for now I think) > >anyway, I think the whole thing could be done in a nice short draft (5 >pages of real text?) > >best wishes, >phil/ > > -----Original Message----- > > From: Bruce Davie [mailto:bdavie@cisco.com] > > Sent: 27 July 2007 18:05 > > To: Steven Blake > > Cc: pcn > > Subject: Re: [PCN] Consensus call: movingdraft-chan-pcn-encoding- > > comparison-00 to working group document > > > > I think the draft needs so much revision at this point that I would > > rather wait for the next version before deciding if it is ready to be > > a WG document. > > > > Specifically, the draft needs to avoid replicating so much material > > from other sources. Almost everything in sections 1 and 2 should be > > removed. The place to define or discuss PCN motivation, terminology, > > architecture, etc., is in other drafts (such as the architecture > > draft). This draft should only reference other drafts. If the authors > > think they need some new terminology, I would urge them to get the > > architecture team to include it in their draft. > > > > This draft should consist of statements like "The approach to PCN > > described in [Reference] requires N distinct packet markings > > (codepoints). These codepoints could be encoded in the following ways: > > - encoding A > > - encoding B > > > > etc. > > > > And then discuss the tradeoffs among the different encoding >approaches. > > > > The authors should be careful to distinguish between the state of a > > *node* and a marking of a *packet* (e.g. a node might be in a > > severely congested state, in which case it wants to be terminating > > some flows, leading to some marking of packets with a "terminate" > > marking. But note that a node will often generate several different > > markings while in a given state, hence states and markings are not > > equivalent.) I think the attempt to make this distinction was what > > led to the notion of "features" which most people (including me) > > seemed to find confusing. > > > > This looks like a pretty major rewrite to me. > > > > Bruce > > > > On Jul 27, 2007, at 10:25 AM, Steven Blake wrote: > > > > > PCN, > > > > > > During the Chicago PCN meeting, the authors of > > > draft-chan-pcn-encoding-comparison-00 asked that this draft become a > > > working group document. Based on the discussion in the room, the >PCN > > > chairs determined that there was no consensus amongst the meeting > > > participants to move this version of the draft to a working group > > > document at this time. There was a comment made that if certain > > > simplifications were made in the next version of the draft (e.g., > > > reducing the amount of text on marking semantics and concentrating >on > > > syntax), then the draft then would be ready to move to working group > > > document. The chairs asked the authors to consider this approach. > > > More > > > details of the discussion will be available when the meeting > > > minutes are > > > posted. > > > > > > This email is a request for comments on moving > > > draft-chan-pcn-encoding-comparison-00 to working group document. > > > Please > > > send your comments to the list within the next week. > > > > > > > > > Scott & Steve > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Steven Blake > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 30 15:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQptX-0007iB-6M; Thu, 30 Aug 2007 15:41:35 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IQptV-0007i1-Qk for pcn-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 15:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQptV-0007ht-Gm for pcn@ietf.org; Thu, 30 Aug 2007 15:41:33 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQptT-0005XA-MK for pcn@ietf.org; Thu, 30 Aug 2007 15:41:33 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 20:41:30 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 20:41:30 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1188502888973; Thu, 30 Aug 2007 20:41:28 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.3]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7UJfGUW025103; Thu, 30 Aug 2007 20:41:26 +0100 Message-Id: <5.2.1.1.2.20070828142632.03935488@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 30 Aug 2007 20:41:16 +0100 To: "Jozef Babiarz" From: Bob Briscoe Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646511DC4B87@zcarhxm1.corp.nor tel.com> References: <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte.t-com.de> <6439282641581441A36F7F6F83ED2ED201DB9AB7@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Aug 2007 19:41:30.0081 (UTC) FILETIME=[C305AD10:01C7EB3D] X-Spam-Score: -1.0 (-) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: pcn@ietf.org, l.andrew@ieee.org, eeschan@cityu.edu.hk, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, At 15:17 27/08/2007, Jozef Babiarz wrote: >I think there is a bit more to this issue than just different levels of >pre-congestion. > >For admission control the challenge for PCN is to find out how much new >traffic can be added on to a specific link or path and not to determine >the level of congestion. I agree that the AC challenge for PCN is to find how much new traffic can be added, but surely not just for a specific link. The full challenge is for any single ingress edge node to know how much it can add. But it has to accept the fact that it doesn't know how many other ingress nodes are competing to add traffic to the same link. (See previous response to Ruediger - although I don't think you're asking for the same thing, but it sounds like you are). more... >The purpose of admission control is to prevent >congestion of the service class on link that forwards PCN traffic. PCN >is deployed in Diffserv networks, with the understanding that PCN >traffic is forwarded using priority scheduling. > >Voice with silence suppression plus calls naturally ending as well new >calls being added generates highly variable traffic. The marking by >interior node to indicate that PCN admission threshold is exceeded or >not, needs to be quick to reflect true traffic levels. Agreed >Analysis of the >marking density and control of response to the marking can be handled at >the edges. The proposed marking scheme in draft-babiarz-pcn-3sm-00.txt >for admission control, produces the following behavior, when PCN traffic >is fare below the admission stop threshold, no packets are marked. As >the variable traffic increases and some packets exceed the token bucket >rate (admission stop threshold) they are marked. If additional new >traffic is allowed to be admitted on to the link, more packets will >exceed the token bucket rate therefore marking density increases >possibly until all packets are marked. However, for pure and stable CBR >traffic you will get a step marking (on-off) where the transition from >no marking to all packets marked being quick. I'm not sure which you you are saying is more desirable: - the outcome with variable traffic (a gradual transition from 0-100% marking) - or the outcome for CBR traffic (a step change)? I think you're saying that a gradual transition is desirable, but that even with on-off marking you get a gradual transition as long as there's variation in the traffic, which there usually is. (See later for my view) > >My view is that PCN should work equally well regardless of the number of >flows in an ingress-egress aggregate from one to many flows, Agreed. >as well >should work without the need for ingress-egress aggregation concept. If you mean by this, that a new flow shouldn't need to use information from existing flows in an aggregate, I agree. That's a performance enhancement, not an essential function. >The >so called on-off marking approach is not that dependent on the rate of >ingress-egress traffic meaning that edge node will be able to determine >if new flow should be admitted based on low bit rate (probe or single >voice flow) or high bit rate flow(s) passing through the pre-congested >link. I think I am agreeing with you in everything you say, except on one point (if I understand you right). So I'll restate everything I believe, tagged with whether we're agreeing or disagreeing, to try to reach closure, as we've been going round these issues for some time (pre-PCN w-g). Agreement?: A gradual transition in interior admission marking is desirable as the boundary nodes can always turn this into a threshold or use it in innovative ways, to be determined. Agreement?: Whether the transition is gradual is a serious issue, because a distributed measurement-based admission control (DMBAC) system like PCN admits traffic one round trip before it knows whether it should have done. So in a flash crowd (mass calling event) admissions can overshoot if the interior admission marking only flips from 0-100% at the last instant. Whereas if the interior nodes give a gradual increase, the boundary nodes can use the early warning contingency to be more conservative when necessary. Agreement: We hope and expect that traffic levels will be variable because of silence suppression etc. Then step (on-off) marking on interior nodes will be sufficient. It will still lead to a gradual increase in admission marking as the token bucket level goes back and forth across the step, because it will stay increasingly on the marking side the closer the average rate gets to the 'PCN lower rate' ("admission stop threshold" in your terms). Agreement: It would be sufficient to standardise step marking (on-off e.g. 3sm) as a minimum requirement for admission control. Agreement: This would leave one case of pure and stable CBR traffic that would not give a smooth rise in marking, but would toggle from 0 to 100% on the addition of the last flow. Disagreement?: Stable CBR-like traffic won't necessarily be unusual in certain networks. It is certainly possible (tho unlikely) that a particular link may be fed by a large proportion of CBR codecs without silence suppression (e.g. where a network itself deploys a load of cheap codecs for PSTN-emulation). But much more likely are links where the total traffic is CBR-like even tho each flow is variable, due to statistical aggregation of very many variable flows. Disagreement?: The algo shouldn't have to rely on the traffic being variable to behave in the way we want. Ramp marking (as in the body of draft-briscoe-twvwg-cl-phb-03.txt) creates a gradual increase in marking even for CBR-like traffic. Then the marking algo gives a more gradual transition WHATEVER the traffic (unless it's locally shaped to be absolutly pure CBR). The following ASCII art illustrates this. Even for step marking, the curve of marking probability against mean arrival rate is smoother for traffic with more variance, but if the traffic doesn't have enough variance, you can push the curve smoother by using a ramp algo. The flatter the ramp, the smoother the curve. ^_ |p, mean marking probability | | | | !| | !| | !| | ;| | ,;| | ,;| | |;| | |;| | variance ;;| | of total PCN / || | traffic on link, | || | v , || | OR +--- . || | slope of ramp |\ , || | | \ / || | _/ || | __/ \ || | ,--^^ \ || mean | __,,,,----^^^^ \_/ | arrival | /| ______._,_=_=_=_____,,,,,,,,,,......----^\ | rate, +---/ | /----------------------------------------------+------------->_ |/ X x PCN lower rate Agreement: A gradual increase in marking will sometimes lead to a flow being denied that could have been admitted. But that's unavoidable anyway if some flows are variable - we even had that trade-off to an extent even in Intserv-style admission control. However, ramp marking makes the range of rates over which you get under-admission wider than it was with just natural traffic variability. Agreement?: * For a link with a large number of flows with high statistical multiplexing, the benefit of artifically creating a gradual increase using ramp marking outweighs the cost. You get early warning of a flash crowd but miss the odd flow unnecessarily (when the system hits its admission limit, which should be rare anyway). * For a link only carrying a small number of flows within its PCN lower rate, the cost of ramp marking in under-admissions outweighs its benefit. Note, this needen't be a low capacity link - it might be a high capacity link with a few large flows. * For a link in between - with high number of flows but not high enough stat mux to smooth to CBR-like, the traffic variance may give enough of a gradual increase to handle flash crowds without needing to add more smoothness using ramp marking (ie cost of ramp under-admissions outweights benefit of more smoothness when you've got enough anyway). Agreement?: Note: links with a few flows fall outside the PCN charter, but that shouldn't stop us prefering solutions that handle such links, all other issues being equal. Agreement?: If I'm right in all this, I believe we should allow and encourage (but not mandate) vendors to implement ramp marking on machines targeted for PCN interior nodes (ie SHOULD implement ramp). Then ramp is available if it's needed, but can be turned off if it isn't. Agreement?: But we should advise that step marking is the best solution (ie SHOULD deploy step) if there's enough variability in the traffic anyway (or only a few flows are expected on the link). Agreement?: But ramp marking is hard to do on much current hardware. So it's useful that it's not a MUST. However, if an operator needs ramp marking (a risk of flash crowds and links with smoothly aggregated traffic) we should caution that inability to deploy ramp is NOT a good reason for not deploying it. Disagreement: You imply that, with low packet probing rates, step (on-off) marking can determine whether to admit a new flow faster than ramp. Given both have a range over which they mark packets probabilistically, I don't believe this is the way to state the distinction between them. Certainly ramp marks packets probabilistically over a wider range of loads. But, for either algo, the ingress boundary node doesn't know whether an interior node is within this range or not when it probes. So it has to send as many probes in both cases in case an interior node might be in its probabilistic range of marking. Disagreement?: In fact, ramp actually gives a much quicker probing time than step: * Step: If the queue is above the step 5% of the time due to traffic variation, over a *long* time period it will indeed mark 5% of probes. BUT over a *short* period it will mark all the probes the same (queue length correlation over time). * Ramp: If the queue is varying around the point on the ramp that is doing 5% marking, it will mark each probe with ~5% probability, independently of how it marked previous ones. So, with either algo you have to send the same number of probes, but with ramp you can send them back-to-back, while with step you get hardly any more information unless you send them spaced over a long time period (ie a few seconds). Hence ramp should be much quicker to probe. Pls say whether you agree or disagree with each point, so we can home in on exactly why we keep both going round this loop. Cheers Bob >Regards, Joe >email:babiarz@nortel.com >Telephone:613-763-6098 >-----Original Message----- >From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >Sent: August 24, 2007 3:09 AM >To: l.andrew@ieee.org; rbriscoe@jungle.bt.co.uk >Cc: pcn@ietf.org; eeschan@cityu.edu.hk >Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking > >Lachlan, Bob, > >you both seem to agree that ramp marking is the best solution. >Picking up Lachlan's pretty sound arguments on different thresholds >for different types of incoming calls - what you describe is >estimating the available (not consumed) PCN bandwidth rather than >just a "pre congestion notification", I think. >If there's a simple solution to realize this idea, PCN should >investigate it. This could be helpful if there's a new call to be >admitted and no PCN flow exists between two gateways. The question >then would be, whether a certain bandwidth is available, rather >than "any congestion visible". ToDo: * an edge ingress node needs to use its own knowledge of its own rate contribution to the problem (x). 0 <= p <= 1 Bob >Regards, > >Ruediger > > >|Lachlan wrote: >|I believe that the marking scheme should carry as much information as >|possible about the network state, and that thresholding should be done >|as late as possible (at the decision-making end-points). The more >|information the decision-making entity has, better the decisions it >|can make. >| >|If things like thresholding are done where the admission decisions are >|made, there is also a smoother upgrade path for changes in the >|admission rules. For example, an operator may want to apply different >|thresholds applied to different types of incoming calls. If routers >|provide a single threshold, this can't be implemented at a later >|stage. Similarly, an operator may want to admit a certain percentage >|of traffic dependent on the congestion level, rather than admitting >|all or none. > >|Bob wrote: >|[BB] The problem we were trying to solve with ramp marking was the >|reverse: >|we were looking for a marking algo that produced a smooth increase in >|marking over a wider range of loads. The edge nodes can always turn a >|smooth rise into a toggle at a specific threshold marking level. > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 31 02:46:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR0Gc-0000mx-Nn; Fri, 31 Aug 2007 02:46:06 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IR0Gb-0000mr-R3 for pcn-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 02:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR0GX-0000mh-Ut for pcn@ietf.org; Fri, 31 Aug 2007 02:46:01 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR0GW-0002mO-5I for pcn@ietf.org; Fri, 31 Aug 2007 02:46:01 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 31 Aug 2007 08:45:56 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 08:45:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture new section on tunnelling Date: Fri, 31 Aug 2007 08:45:55 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB9B29@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC403@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture new section on tunnelling thread-index: AcfevdVkvekXSAdHR5aLqYZsjoBFagERiMywAiU4pNA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 31 Aug 2007 06:45:56.0329 (UTC) FILETIME=[95285D90:01C7EB9A] X-Spam-Score: -1.0 (-) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, is the mentioned "knowing what the PCN-ingress-node is, done=20 at the signaling level" described in more detail in one of=20 the documents already? RSVP is not supposed to be tunneled to all places. If a PCN=20 related RSVP message is tunneled through a PCN ingress router,=20 the tunnel terminates in the middle of a PCN domain and the=20 RSVP message continues through a PCN domain egress, I'd=20 regard this as a security incident. May be the message should=20 simply be ignored - dropping is another alternative. The=20 possibility to insert RSVP (or other signaling messages) that=20 way requires authentication for the signaling between PCN=20 ingress and egress nodes. Regards, Ruediger |-----Original Message----- |From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] |Sent: Monday, August 20, 2007 10:46 AM |To: menth@informatik.uni-wuerzburg.de; babiarz@nortel.com |Cc: pcn@ietf.org |Subject: RE: [PCN] PCN architecture new section on tunnelling | | |Michael | |Good points. To me your tunnelling analysis is another example of |multi-path; like ECMP it's quite tricky for PCN.=20 | |for flow termination, this can be solved by terminating flows that are |actually marked (3sm-draft is one example, the Briscoe-cl-architecture |gave another).=20 | |For adm ctrl, the solutions seem to be:=20 |- tunnel all traffic between PCN-ingress-node and PCN-egress-node (I | think this works for your tunnelling examples as well as for ECMP) |- accept the adm decision is approximate;=20 |- do probing for each flow admission | |in terms of knowing what the PCN-ingress-node is (so that you=20 |know where to do policing to enforce the adm decision), wouldn't=20 |this still be done at the signalling level? I suppose the=20 |question is then what happens if eg rsvp is tunnelled? | |phil | |> -----Original Message----- |> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |> Sent: 14 August 2007 22:52 |> To: Jozef Babiarz |> Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org |> Subject: Re: [PCN] PCN architecture new section on tunnelling |>=20 |> Hi, |>=20 |> Imagine a packet is tunneled from node A to some other node B, it is |> decapsulated there and forwarded to destination C. Then, the traffic |> takes the route from A over B to C. |> 1st problem: how do we find the ingress node X of the packet at its |PCN |> egress Y? |> 2nd problem: provided that we know the ingress node X, the=20 |path from A |> over B to C does not necessarily coincide with normal IP routed path |> from the corresponding PCN ingress X to egress Y. If those=20 |packets are |> admission marked, they may cause admission stop for traffic from X to |Y |> although they take a different path. |>=20 |> Thus, the problem is that we associate the=20 |admission-stop-marking with |> the path from the ingress to the egress of the packet. If the packet |> took a different path than by typical IP routing, the interpretation |of |> the PCN information is leads to the wrong conclusions. Similar |problems |> occur with excess-traffic-marked packets if the corresponding PCN |> information is associated with the path. The marked flow termination |> (MFT) from the 3sm-draft associates the marking with the flow and can |> cope well with arbitrarily routed flows. |>=20 |> Possible solution: the marking from X to B needs to be evaluated at B |> and be associated with the path from X to B, and the marking received |> from B to Y needs to be evaluated at Y and be associated=20 |with the path |> from B to Y. |>=20 |> I just want to say: tunneling with tunnel endpoints in PCN=20 |networks is |> not yet understood. |>=20 |> Best wishes, |>=20 |> Michael |>=20 |> Jozef Babiarz wrote: |> > |> > Phil, please see my comment below demarked with [Joe]. |> > |> > /Regards, Joe/ |> > email:babiarz@nortel.com |> > Telephone:613-763-6098 |> > |> > |--------------------------------------------------------------- |--------- |> > |> > *From:* philip.eardley@bt.com [mailto:philip.eardley@bt.com] |> > *Sent:* August 8, 2007 6:14 PM |> > *To:* pcn@ietf.org |> > *Subject:* [PCN] PCN architecture new section on tunnelling |> > |> > This is to flag up that I wrote a new sub-section (in Section 5, |> > Detailed functional architecture) about tunelling: |> > |> > 5.8. Tunnelling |> > |> > It is possible that tunnels terminate at a PCN-node. It is=20 |important |> > |> > that any PCN-marking is preserved after decapsulation, so=20 |that it is |> > |> > still seen by the PCN-egress-node. To ensure this, on decapsulation |> > |> > the following rules are applied: |> > |> > o the PCN-marking state of the inner and outer headers are compared |> > |> > o if the inner header's marking state is more severe then it is |> > |> > preserved |> > |> > o if the outer header's marking state is more severe then it is |> > |> > copied onto the inner header |> > |> > o NB the order of increasing severity is: unmarked;=20 |PCN-marking with |> > |> > first encoding (ie associated with the PCN-lower-rate); PCN- |> > |> > marking with second encoding (ie associated with the PCN-upper- |> > |> > rate) |> > |> > Similarly, if encapsulation is done within the PCN-domain, then the |> > |> > following rule is applied: |> > |> > * any PCN-marking is copied into the outer header |> > |> > [Joe] The above may introduce unnecessary information leakage. Why |not |> > just at the encapsulation point mark all packets as unmarked. The |> > decapsulation point can sort them out. Just realizes that excess |rate |> > marking approach will not work unless PCN-marking information is |> > copied from inner to outer headers when encapsulating. [end] |> > |> > [Joe] I'm assuming for time being that "PCN nonce" (similar to ECN |> > nonce) is out of scope as we are not sure if it's need for PCN. If |not |> > than the "PCN nonce" would also need to be copied to outer header. |[end] |> > |> > Tunnelling considerations also depend on which header bits the PCN |WG |> > |> > decides to use. If the ECN bits are used then |> > |> > [I-D.briscoe-tsvwg-ecn-tunnel] applies; the rules above conform to |> > |> > its spirit. If the DSCP field is used then [RFC2983] needs to be |> > |> > considered carefully. |> > |> > An operator may wish to tunnel PCN-traffic from=20 |PCN-ingress-nodes to |> > |> > PCN-egress-nodes, in which case the rules above aren't needed. The |> > |> > potential reasons for doing such tunnelling are: the=20 |PCN-egress-node |> > |> > then automatically knows the address of the relevant |PCN-ingress-node |> > |> > for a flow; even if ECMP is running, all PCN-packets on a=20 |particular |> > |> > ingress-egress-aggregate follow the same path. But it also has |> > |> > drawbacks: additional overhead in terms of bandwidth and=20 |processing; |> > |> > and the effective elimination of ECMP as a load balancing=20 |mechanism. |> > |> > |--------------------------------------------------------------- |--------- |> > |> > _______________________________________________ |> > PCN mailing list |> > PCN@ietf.org |> > https://www1.ietf.org/mailman/listinfo/pcn |> > |>=20 |> -- |> 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://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn