From pcn-bounces@ietf.org Sat Dec 01 14:15: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 1IyXnU-00049M-6N; Sat, 01 Dec 2007 14:14:40 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IyXnS-00047z-P8 for pcn-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:14:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXnS-00046P-DQ for pcn@ietf.org; Sat, 01 Dec 2007 14:14:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyXnQ-0002oX-MH for pcn@ietf.org; Sat, 01 Dec 2007 14:14:38 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1A0FC204FD; Sat, 1 Dec 2007 20:13:41 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-40-4751b2645323 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E9F4F210F8; Sat, 1 Dec 2007 20:13:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 20:13:40 +0100 Received: from [138.85.12.58] ([138.85.12.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 20:13:40 +0100 Message-ID: <4751B261.9090503@ericsson.com> Date: Sat, 01 Dec 2007 20:13:37 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [PCN] some comments on pcn-architecture-02 References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2007 19:13:40.0514 (UTC) FILETIME=[484CB820:01C8344E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Hancock, Robert skrev: > > 6. On the specific point about what to do with PCN flows using ECN, I > can just about follow the logic > - if CE was set, then it is possible that it was set by a router using > the default ECN semantics > - a router using the default ECN semantics should be able to assume that > the receiver would react in a similar way as to a packet drop > - therefore the PCN domain can drop the packet > However, it's quite a long journey from the beginning of the argument to > the end. In particular, for an endpoint, receiving a packet with CE is > quite different from not receiving a packet at all. For one thing, it > means the receiver gets data. It also gets a positive signal of > congestion (rather than, for example, wondering whether it was a > congestive or corruptive packet loss). In general, I think it's really > important not to do things which act as deployment disincentives for > ECN, or any additional barriers to alternative semantics, since e2e > packet marking is so useful for congestion control in some environments > (multi-hop wireless in particular). > > If the desire is to have a simple solution for PCN which uses the ECN > bits for encoding, there might be an alternative: if you detect that a > PCN-flow is using ECN (because ECT is set on any of its packets), simply > reclassify that flow as non-PCN and let it pass transparently through > the domain as non-PCN (e.g. best efforts) traffic. In performance terms > the flow is getting no worse service than in a pre-PCN world. If you > really think that there are no use cases for combined ECN/PCN this > situation will never arise. If applications are developed in the future > which can exploit ECN for semi-elastic flows, then it becomes a question > of writing guidelines for application developers to help them either > interpret signalling protocols (to find out whether their success in > admission control is being harmed by their use of ECN) or split their > flows into elastic and inelastic sub-flows, or indeed work out a PCN > solution which didn't use the ECN bits internally. All of these would > obviously be a later stage of the work. > I think we very well can see traffic that it makes sense to put onto a PCN class in the PCN domain but still use ECN end to end. From my perspective real-time media is never "inelastic" it is rather semi-inelastic in the sense that it commonly can't adapt freely, both because of variable bit-rate depending on the source content and the limited freedom in the encoding to produce different quality/bit-rate tradeoffs. And I have to agree that with ECN you need to have some mechanism to transparent get across the PCN domain if you are ECN enabled or not. Then you have the ECN nonce and the CE marking. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Dec 01 14:23: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 1IyXut-0007fN-7e; Sat, 01 Dec 2007 14:22:19 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IyXus-0007f7-Jq for pcn-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:22:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXus-0007et-6O for pcn@ietf.org; Sat, 01 Dec 2007 14:22:18 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyXur-0006VP-JT for pcn@ietf.org; Sat, 01 Dec 2007 14:22:18 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DFED821797; Sat, 1 Dec 2007 20:22:16 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-82-4751b468923a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C8BFB21288; Sat, 1 Dec 2007 20:22:16 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 20:22:16 +0100 Received: from [138.85.12.58] ([138.85.12.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 20:22:15 +0100 Message-ID: <4751B463.1050107@ericsson.com> Date: Sat, 01 Dec 2007 20:22:11 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [PCN] Re: ECN support in a PCN domain References: <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2007 19:22:15.0581 (UTC) FILETIME=[7B4DB4D0:01C8344F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: pcn@ietf.org, "ext 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 Lars Eggert skrev: > (I saw the idea in Robert's recent email of "downgrading" ECN-enabled > flows into the best-effort class of PCN. I need to think more about > this, but on first glance this looks like a pretty elegant resolution. A > flow that is ECN-enabled has basically announced to the network that it > will react to loss in some way, i.e., probably has some form of > congestion control. But I need to think about this more.) > Well, that assumes that you never want to run ECN on something that uses PCN. I think that assumption is wrong. A use case for PCN is within a cellular core network. Where you use PCN to ensure that your voice traffic get the best possible QoS through the core network. Even in such a situation you have wireless links that you can't provide any guarantees for and congestion may arise. To my knowledge ECN isn't used yet but could be. I wished we where on clearer ground when it comes to real-time ECN usage. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Dec 01 15:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYcs-0002to-3d; Sat, 01 Dec 2007 15:07:46 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IyYcr-0002ti-92 for pcn-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 15:07:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYcq-0002ta-Ud for pcn@ietf.org; Sat, 01 Dec 2007 15:07:44 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyYcq-00082q-4H for pcn@ietf.org; Sat, 01 Dec 2007 15:07:44 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 793ED21118; Sat, 1 Dec 2007 21:07:43 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-3a-4751bf0f5623 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5F88A210F6; Sat, 1 Dec 2007 21:07:43 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 21:07:43 +0100 Received: from [138.85.12.58] ([138.85.12.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 21:07:42 +0100 Message-ID: <4751BF0B.8080505@ericsson.com> Date: Sat, 01 Dec 2007 21:07:39 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] Re: ECN support in a PCN domain References: <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2007 20:07:42.0598 (UTC) FILETIME=[D4BB7A60:01C83455] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Geib, Ruediger skrev: > Lars, > > my own concern about the issue was weaker (behaviour of an ingress node > in the case of a possible misuse of PCN colouring from an external > interface). > > But I agree, the congestion feedback received by an end node is an > interesting feature and if the WG chairs and the AD feel it to be > important, we should work on it. The charter says, PCN aware > application mechanism and flow adaptation are out of scope. Could > you point out the use case for the legal ECN information received > by the ingress node, if it is not the latter two? I wouldn't express things like this. We ADs are only trying to ensure that PCN has minimal implications on defined and deployed functionality. That include ECN that is deployed and somewhat used. But so far the usage we see is TCP. However, the ECN spec is quite clear that it applies to any protocol. But there is no defined feedback channel for ECN when using UDP. But remember that DCCP do have ECN support. That is why the sentence about ECN exist in the PCN charter. PCN shouldn't prevent ECN from being used down the road, unless we are very certain it is the right way to go. And this requires more than PCN consensus. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Dec 01 15:18:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYmL-0004pb-QW; Sat, 01 Dec 2007 15:17:33 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IyYmK-0004pO-Eq for pcn-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 15:17:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYmK-0004pG-5J for pcn@ietf.org; Sat, 01 Dec 2007 15:17:32 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyYmI-0004uO-FO for pcn@ietf.org; Sat, 01 Dec 2007 15:17:32 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C74E820CCF; Sat, 1 Dec 2007 21:17:29 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-86-4751c159332e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AA74820798; Sat, 1 Dec 2007 21:17:29 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 21:17:29 +0100 Received: from [138.85.12.58] ([138.85.12.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 21:17:28 +0100 Message-ID: <4751C155.6080408@ericsson.com> Date: Sat, 01 Dec 2007 21:17:25 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Steven Blake Subject: Re: [PCN] Open issues on architecture draft. References: <75A199C5D243C741BF3D3F1EBCEF9BA503B3439E@E03MVZ1-UKDY.domain1.systemhost.net> <1196275643.5664.45.camel@neutrino> In-Reply-To: <1196275643.5664.45.camel@neutrino> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2007 20:17:29.0012 (UTC) FILETIME=[32432740:01C83457] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Steven Blake skrev: > Philip et. al., > > I think there are open issues surrounding Sec. 5.6, > namely: > > - how an egress node associates a received packet with an > ingress-egress aggregate > > - whether centralized nodes are in scope for the architecture > > Regarding the former: I don't believe that it is the responsibility of > PCN to mandate a mechanism for making the packet->aggregate association, > nor is it our responsibility to define protocol mechanisms to facilitate > this (although I would appreciate input from the ADs). It would be good > to discuss the issue in more detail in the document; e.g., list > alternatives, discuss trade-offs, etc. I think the discussion on the alternatives are very important. I actually noticed this in my own reading of the architecture document. We need to understand what the possibilities and their implications actually are. What complexities and trade off does the different methods for locating the ingress node mean for PCN. I don't understand this now. When it comes to mandating one solution, I don't think the architecture itself should do that. For specific deployment configurations that will of course be necessary. However, I am still not certain if this will be IETF's role at all for PCN. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Dec 02 08:11: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 1Iyoau-0000iQ-NK; Sun, 02 Dec 2007 08:10:48 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iyoat-0000iA-BG for pcn-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 08:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyoat-0000i2-1e for pcn@ietf.org; Sun, 02 Dec 2007 08:10:47 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyoas-0001u9-CQ for pcn@ietf.org; Sun, 02 Dec 2007 08:10:47 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id lB2DAOLp027953; Sun, 2 Dec 2007 13:10:24 GMT Received: from ehlaptop ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 13:10:23 +0000 From: "Robert Hancock" To: "'Magnus Westerlund'" , "'Lars Eggert'" References: <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de> <4751B463.1050107@ericsson.com> Subject: RE: [PCN] Re: ECN support in a PCN domain Date: Sun, 2 Dec 2007 13:10:12 -0000 Message-ID: <002801c834e4$b1237d20$0100c80a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg0T6QVa1Yi3JNySpOvXGnkOhn4pwAk31BA In-Reply-To: <4751B463.1050107@ericsson.com> X-OriginalArrivalTime: 02 Dec 2007 13:10:24.0170 (UTC) FILETIME=[B31450A0:01C834E4] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: -1.0 (-) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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, > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Lars Eggert skrev: > > (I saw the idea in Robert's recent email of "downgrading" > ECN-enabled > > flows into the best-effort class of PCN. I need to think more about > > this, but on first glance this looks like a pretty elegant > resolution. > > A flow that is ECN-enabled has basically announced to the > network that > > it will react to loss in some way, i.e., probably has some form of > > congestion control. But I need to think about this more.) > > > > Well, that assumes that you never want to run ECN on > something that uses PCN. I think that assumption is wrong. A > use case for PCN is within a cellular core network. Where you > use PCN to ensure that your voice traffic get the best > possible QoS through the core network. Even in such a > situation you have wireless links that you can't provide any > guarantees for and congestion may arise. To my knowledge ECN > isn't used yet but could be. > > I wished we where on clearer ground when it comes to > real-time ECN usage. To be clear, I am quite happy with there being use cases for ECN being used with traffic that also goes through an admission control process for some sort of capacity reservation (indeed, I can think of some additional ones). I think the only reason ECN concepts are so closely associated with TCP is the relative lack of other sorts of traffic in the wild until quite recently. So, the point is not to claim that ECN and PCN should never be used together. Rather, it's to suggest that if it's the case that even *if* it's impossible to find a PCN solution which both - is simple enough to get initial deployment, and - avoids trampling the ECN bits then there is still a case for a simple PCN solution which only helps non-ECN traffic if it also does no harm to ECN traffic. PCN will be better than nothing for some traffic, and not worse than the status quo for everything else. A PCN solution which is better than nothing for all traffic could be a subsequent evolution. (Really I guess this is all a discussion about whether there are simple, feasible solutions which 'cleanly integrate with ECN' in the language of the charter.) robert h. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 03 03:07: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 1Iz6KJ-0000WG-Ho; Mon, 03 Dec 2007 03:06:51 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iz6KH-0000JX-IB for pcn-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6K9-00089X-G3 for pcn@ietf.org; Mon, 03 Dec 2007 03:06:41 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz6K7-0004eX-Kc for pcn@ietf.org; Mon, 03 Dec 2007 03:06:41 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 3 Dec 2007 09:04:23 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Dec 2007 09:04:22 +0100 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] Re: ECN support in a PCN domain Date: Mon, 3 Dec 2007 09:04:21 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C15AB@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4751BF0B.8080505@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: ECN support in a PCN domain Thread-Index: Acg0Vd/W0s6Z9f4vQgCdVJodVTyG5QBLCxPA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 03 Dec 2007 08:04:22.0602 (UTC) FILETIME=[1D2522A0:01C83583] X-Spam-Score: -1.0 (-) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Magnus, your response sounds to me like - off PCN charter: definition of end system behaviour once=20 ECN pre-congestion indication or feedback is received. - on PCN charter: transport of ECN information to an=20 end system. I'd like to be clear on what's expected form the PCN WG. Regards, Rudiger |-----Original Message----- |From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] |Sent: Saturday, December 01, 2007 9:08 PM |To: Geib, R=FCdiger |Cc: pcn@ietf.org |Subject: Re: [PCN] Re: ECN support in a PCN domain | | |Geib, Ruediger skrev: |> Lars, |>=20 |> my own concern about the issue was weaker (behaviour of an=20 |ingress node=20 |> in the case of a possible misuse of PCN colouring from an external=20 |> interface).=20 |>=20 |> But I agree, the congestion feedback received by an end node is an=20 |> interesting feature and if the WG chairs and the AD feel it to be=20 |> important, we should work on it. The charter says, PCN aware=20 |> application mechanism and flow adaptation are out of scope. Could |> you point out the use case for the legal ECN information received=20 |> by the ingress node, if it is not the latter two? | |I wouldn't express things like this. We ADs are only trying to ensure |that PCN has minimal implications on defined and deployed=20 |functionality. |That include ECN that is deployed and somewhat used. But so far the |usage we see is TCP. However, the ECN spec is quite clear that it |applies to any protocol. But there is no defined feedback channel for |ECN when using UDP. But remember that DCCP do have ECN support. | |That is why the sentence about ECN exist in the PCN charter. PCN |shouldn't prevent ECN from being used down the road, unless we are very |certain it is the right way to go. And this requires more than PCN |consensus. | |Cheers | |Magnus Westerlund | |IETF Transport Area Director & TSVWG Chair |---------------------------------------------------------------------- |Multimedia Technologies, Ericsson Research EAB/TVM |---------------------------------------------------------------------- |Ericsson AB | Phone +46 8 4048287 |Torshamsgatan 23 | Fax +46 8 7575550 |S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.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 Mon Dec 03 04:44: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 1Iz7qA-0005Ut-6B; Mon, 03 Dec 2007 04:43:50 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iz7q8-0005Uh-Eq for pcn-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 04:43:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7q8-0005UX-3s for pcn@ietf.org; Mon, 03 Dec 2007 04:43:48 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz7q7-0003Mg-Eg for pcn@ietf.org; Mon, 03 Dec 2007 04:43:48 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 3 Dec 2007 10:42:51 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Dec 2007 10:42:50 +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: [PCN] Supported congestion notifcation mechanisms of a PCN domain Date: Mon, 3 Dec 2007 10:42:50 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C15AD@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: ECN support in a PCN domain Thread-Index: AcgzqXjjbUvLJMFwQ1WfKFb381XH4QB2aZlg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 03 Dec 2007 09:42:50.0489 (UTC) FILETIME=[DE852690:01C83590] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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, we've had the discussion on the traffic passing a PCN domain with=20 the same DSCP earlier. That discussion ended saying there may be=20 traffic with the same DSCP as PCN traffic, but not supporting=20 PCN mechanisms. Based on this, the following options=20 may apply on the traffic sharing the same queue and DSCP: - not PCN aware, not ECN aware - not PCN aware, ECN aware - PCN aware, not ECN aware - PCN aware, ECN aware The minimum amount of coding space for PCN to transmit everything transparently is defined by the single codepoint marking approach.=20 That would mean: - one codepoint indicating no PCN support - one codepoint indicating PCN support - one codepoint indicating PCN pre-congestion - one codepoint indicating ECN support - one codepoint indicating ECN pre-congestion - one codepoint indicating ECN and PCN pre-congestion=20 No matter what we do, 4 ECN codepoints are insufficient to=20 transmit this information. What to do then? - use a separate DSCP for ECN traffic or for not PCN aware traffic=20 (which may also mean usage of another traffic class) - apply tunnels from ingress to egress for ECN aware=20 traffic. Tunnels require another control plane. I don't suggest addition of a=20 tunnel protocol to PCN unless one is already operational (like MPLS). So I prefer separate DSCPs for IP based PCN domains. I'm of course=20 happy to have some more discussion (and even happier I would be, if=20 there was fast consensus..). Regards, Rudiger -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Saturday, December 01, 2007 12:33 AM To: Geib, Rudiger Cc: pcn@ietf.org Subject: Re: [PCN] Re: ECN support in a PCN domain On 2007-11-29, at 0:02, ext Geib, Ruediger wrote: > But I agree, the congestion feedback received by an end node is an > interesting feature and if the WG chairs and the AD feel it to be > important, we should work on it. The charter says, PCN aware > application mechanism and flow adaptation are out of scope. Could > you point out the use case for the legal ECN information received > by the ingress node, if it is not the latter two? Most people think of ECN only in conjunction with TCP, because that's =20 the most common use. But ECN can be used with any transmission scheme =20 that reacts to loss as a signal. For example, a CBR sender might react =20 to loss by suspending transmission. This scheme can be improved =20 through ECN, so that the sender would suspend transmission when ECN =20 marks are received, i.e., before loss occurs. This is why I think that =20 allowing end-to-end ECN to happen in conjunction with PCN is important. (I saw the idea in Robert's recent email of "downgrading" ECN-enabled =20 flows into the best-effort class of PCN. I need to think more about =20 this, but on first glance this looks like a pretty elegant resolution. =20 A flow that is ECN-enabled has basically announced to the network that =20 it will react to loss in some way, i.e., probably has some form of =20 congestion control. But I need to think about this more.) Lars _______________________________________________ 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 Dec 03 14:53: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 1IzHKu-0003Iz-SD; Mon, 03 Dec 2007 14:52:12 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IzHKt-0003CU-9j for pcn-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 14:52:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHKs-0003BH-TP for pcn@ietf.org; Mon, 03 Dec 2007 14:52:10 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzHKs-00037S-48 for pcn@ietf.org; Mon, 03 Dec 2007 14:52:10 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3F4CC214C7 for ; Mon, 3 Dec 2007 20:52:09 +0100 (CET) X-AuditID: c1b4fb3e-b16a4bb00000459d-ee-47545e69b305 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 284E72229D for ; Mon, 3 Dec 2007 20:52:09 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 20:52:09 +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: ECN support in a PCN domain Date: Mon, 3 Dec 2007 20:52:04 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0506579B9B@esealmw109.eemea.ericsson.se> In-Reply-To: <002801c834e4$b1237d20$0100c80a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: ECN support in a PCN domain Thread-Index: Acg0T6QVa1Yi3JNySpOvXGnkOhn4pwAk31BAAD73VmA= References: <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de><4751B463.1050107@ericsson.com> <002801c834e4$b1237d20$0100c80a@comm.ad.roke.co.uk> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 03 Dec 2007 19:52:09.0046 (UTC) FILETIME=[FD1E3F60:01C835E5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 Because of the discussion of the possible use of ECN for other things than TCP, below a collection of refrences with potential use cases that perhaps highlights the benefits of being able to keep ECN transparent end2end even through a PCN domain without the need to downgrade to best effort or something similar.=20 Regards Ingemar =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= Thesis reports: Fredrik Hultin "Congestion notification and rate-adaptation for real-time services in All-IP radio networks"=20 http://epubl.ltu.se/1402-1617/2007/244/LTU-EX-07244-SE.pdf Sarker, A.N.M. Zaheduzzaman "A study on adaptive real time video over LTE " http://epubl.ltu.se/1653-0187/2007/064/LTU-PB-EX-07064-SE.pdf The two thesis reports was written in parallel where the first dealt with the network and the second dealt with the application. There is also ongoing some work regarding this in 3GPP, below a collection of documents that may be of interest. =20 S4-070563:Real-time adaptive communication services in LTE http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_45/Docs/S4-070563.zip Mentions only the word "congestion warning" but refers to...=20 S2-073328:Rate adaptation with "MBR>GBR bearers" =20 http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_59_Helsinki/Docs/S2-073328 .zip Describes how ECN can be used for MBR<->GBR bearers Additionally: S2-075184: http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518 4.zip S2-075185: http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518 5.zip Latest documents in 3GPP RAN2 that deals with the use of ECN =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= =20 > -----Original Message----- > From: Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 > Sent: den 2 december 2007 05:10 > To: Magnus Westerlund; 'Lars Eggert' > Cc: pcn@ietf.org > Subject: RE: [PCN] Re: ECN support in a PCN domain >=20 > hi,=20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Lars Eggert skrev: > > > (I saw the idea in Robert's recent email of "downgrading"=20 > > ECN-enabled > > > flows into the best-effort class of PCN. I need to think=20 > more about=20 > > > this, but on first glance this looks like a pretty elegant > > resolution.=20 > > > A flow that is ECN-enabled has basically announced to the > > network that > > > it will react to loss in some way, i.e., probably has=20 > some form of=20 > > > congestion control. But I need to think about this more.) > > >=20 > >=20 > > Well, that assumes that you never want to run ECN on something that=20 > > uses PCN. I think that assumption is wrong. A use case for PCN is=20 > > within a cellular core network. Where you use PCN to ensure=20 > that your=20 > > voice traffic get the best possible QoS through the core=20 > network. Even=20 > > in such a situation you have wireless links that you can't=20 > provide any=20 > > guarantees for and congestion may arise. To my knowledge ECN isn't=20 > > used yet but could be. > >=20 > > I wished we where on clearer ground when it comes to real-time ECN=20 > > usage. >=20 > To be clear, I am quite happy with there being use cases for=20 > ECN being used with traffic that also goes through an=20 > admission control process for some sort of capacity=20 > reservation (indeed, I can think of some additional ones). I=20 > think the only reason ECN concepts are so closely associated=20 > with TCP is the relative lack of other sorts of traffic in=20 > the wild until quite recently. >=20 > So, the point is not to claim that ECN and PCN should never=20 > be used together. Rather, it's to suggest that if it's the=20 > case that even *if* it's impossible to find a PCN solution which both > - is simple enough to get initial deployment, and > - avoids trampling the ECN bits > then there is still a case for a simple PCN solution which=20 > only helps non-ECN traffic if it also does no harm to ECN traffic. > PCN will be better than nothing for some traffic, and not=20 > worse than the status quo for everything else. A PCN solution=20 > which is better than nothing for all traffic could be a=20 > subsequent evolution. >=20 > (Really I guess this is all a discussion about whether there=20 > are simple, feasible solutions which 'cleanly integrate with=20 > ECN' in the language of the charter.) >=20 > robert h. >=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 Mon Dec 03 20:51:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMwY-0003P8-K7; Mon, 03 Dec 2007 20:51:26 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IzMwX-0003Ox-MU for pcn-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:51:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMwX-0003ON-C1 for pcn@ietf.org; Mon, 03 Dec 2007 20:51:25 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzMwW-00077Z-W8 for pcn@ietf.org; Mon, 03 Dec 2007 20:51:25 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 61E4B20530; Tue, 4 Dec 2007 02:51:24 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-f8-4754b29cfd95 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4D67020948; Tue, 4 Dec 2007 02:51:24 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 02:51:24 +0100 Received: from [153.88.14.246] ([153.88.14.246]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 02:51:23 +0100 Message-ID: <4754B29A.5080909@ericsson.com> Date: Mon, 03 Dec 2007 17:51:22 -0800 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] Re: ECN support in a PCN domain References: <1B6169C658325341A3B8066E23919E1C4C15AB@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C15AB@S4DE8PSAANK.mitte.t-com.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2007 01:51:23.0852 (UTC) FILETIME=[2CC8A0C0:01C83618] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Geib, Ruediger skrev: > Magnus, > > your response sounds to me like > > - off PCN charter: definition of end system behaviour once > ECN pre-congestion indication or feedback is received. Did you mean ECN congestion indication? I think one can't only talk about congestion indication, but also the ECN enabled. But independent of either you are correct that it is true that it is of charter to define end-system response, beyond session admission or termination. > > - on PCN charter: transport of ECN information to an > end system. In the sense that the information flow for ECN is capable of making it across a PCN domain. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 03 21:00: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 1IzN53-0004RS-Rz; Mon, 03 Dec 2007 21:00:13 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IzN53-0004Qp-3z for pcn-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 21:00:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzN52-0004Qg-Ob for pcn@ietf.org; Mon, 03 Dec 2007 21:00:12 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzN51-0007xy-P0 for pcn@ietf.org; Mon, 03 Dec 2007 21:00:12 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 02:00:15 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 02:00:15 +0000 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 1196733608990; Tue, 4 Dec 2007 02:00:08 +0000 Received: from mut.jungle.bt.co.uk ([10.73.80.2]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id lB41xTmY018620; Tue, 4 Dec 2007 01:59:43 GMT Message-Id: <5.2.1.1.2.20071204011609.022d5750@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 04 Dec 2007 01:59:48 +0000 To: "Kwok-Ho Chan" From: Bob Briscoe Subject: Re: [PCN] PCN Encoding Comparison Draft Open Issues In-Reply-To: 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: 04 Dec 2007 02:00:15.0438 (UTC) FILETIME=[69A236E0:01C83619] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 Kwok, Issue #3e Is(are) "nounce" encoding state(s) needed? Some background, then my opinion at the end... Validation of a nonce is typically done by taking the sum of all the nonces between one feedback signal and the next. In general this requires identifiable checkpoints to start and end the calculation over all the intevening nonces. Therefore, between PCN boundary nodes, a nonce only works if the packets can be reliably identified and ordered in the same way by the ingress and the egress. As PCN ingress nodes don't add sequence numbers or use existing sequence numbers and the egress doesn't read sequence numbers or correct any misordering, a nonce would not ever be ever able to be reliably validated by the boundary nodes. The only possible need for the nonce is if ECN is also being used e2e, and the endpoints validate the ECN nonce with their knowledge of packet ordering. What would be the implication of re-using an ECN-nonce codepoint if the source did deploy the nonce? Let's imagine the PCN w-g decided to re-use one of the ECN nonce codepoints for (say) admission marking. If a source encoded a nonce into a packet stream but the PCN ingress overwrote the nonce codepoint to ensure it wasn't misinterpreted as (say) admission marking within the PCN domain, the source would think that something along the path or the receiver was 'cheating' in some way. In RFC3540 it's up to the source what to do in this case. It might stop sending if it thinks the receiver is cheating. But nothing would break if the source decided to just carry on even tho something might be cheating. However, a bad precedent would be set overloading a header codepoint without any negotiation mechanism. RFC3540 (the ECN nonce) is experimental having attained that status in Jun 03. It hasn't been implemented by anyone (yet), except one instance by the main author which has not been deployed or made available as binary or source. My tuppence worth would be that, if we decide to somehow use the ECN codepoints for PCN codepoints, there would be no problem also re-using the ECN nonce for PCN codepoints. Ie, PCN can't use a nonce itself (because of the re-ordering issues above). HTH Bob At 19:46 30/11/2007, Kwok-Ho Chan wrote: >If you have problem with the link to the Issues List, >You can use the link: >http://standards.nortel.com/pcn/PCN_Encoding_Comparison_Draft_OpenIssues.txt > >Sorry for any inconvenience. >-- Kwok -- > >At 02:26 PM 11/30/2007, you wrote: >>The current open issues for: >>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-01.txt >>are documented at: >>http://standards.nortelnetworks.com/pcn/PCN_Encoding_Comparison_Draft_OpenIssues.txt >> >>This file will be updated based on discussions and resolutions of these >>and additional >>open issues for the draft. >> >>Please review the draft and the issues list. >> >>E-Mail list discussions on the open issues should have: >>"EC Issue 03.c" as the start of the E-Mail subject field for >>"PCN Encoding Comparison Draft Issue 3 Sub-Issue a" >>to help multiple drafts, multiple issues, discussion management. >> >>Please let me know if you want any changes/corrections/additions to this >>file. >>For example: the creation of a new issue, or sub-issue of an existing issue. >> >>I have the content of the Issues List cut-and-pasted below in this E-Mail. >>But will be using the file as the master copy going forward. >> >>Thank you very much for your time and attention to this work. >>-- Kwok -- >> >> >>Content of the PCN Encoding Comparison Draft Issues List file: >> >>Issues List for PCN Encoding Comparison Draft >>============================================= >>Updated: Nov 28, 2007 >>Editor: Kwok Ho Chan >>Draft: >>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-01.txt >> >>For further discussions, please use notations of: >>- EComp03.c is used to reference Encoding Comparison draft Issue "03.c". >>- "chan-01" is used to reference version -01 of the personal draft. >> >> >>Issue #1: ECN Support in a PCN Domain >>===================================== >>The resolution of this issue will clarify how a PCN Domain needs >>to treat ECN (RFC3168) packets, in terms of Interior Nodes and >>Edge Nodes. This issue arise with discussion on the Architecture >>draft, but this will definitely impact the PCN Encoding Comparison >>draft, with possible impact on the algorithm discussions. >>The resolution of this issue will also solidify the definition of >>a PCN Domain. >>The starting point will be: Does the use of DiffServ sufficiently >>define the logical boundaries of a PCN Domain? Logical because >>the same physical network device (router,switch,etc) may support >>a PCN Domain as well as some other non-PCN domains. >> >> >>Issue #2: Deletion of the Out of Band Channel Section >>===================================================== >>It have been proposed to remove chan-01 section 3.4 Out-of-Band >>Channel as Encoding Transport. This is considered to be out of scope >>for the WG. Would like some agreements on the list before removal. >> >> >>Issue #3: Encoding States >>========================= >>The Encoding States indicated in chan-01 section 2 Encoding Requirements >>needs to be better defined and clarified. >>More specifically: >>a. Removing PCN Capable Transport Marking (Non-PCN Capable Transport >> Marking) as a notion of Encoding State, just indicate the need >> for this separation as a requirment (possibly in the Architecture). >>b. Better explanation/indication of Single Marking for both Admission >> Marking and Termination Marking >>c. Possible additional encoding choices when DSCP+ECN fields are used. >>d. Which Encoding States should the WG require? >> Should there be optional Encoding States? >> And their deployment options. >>e. Is(are) "nounce" encoding state(s) needed? >> >> >>Issue #4: Encoding Option Evaluation Criteria >>============================================= >>Need to add a section that indicates and describes the encoding option >>evaluation criteria. May want to add OAM impacts/considerations here or in >>some new section. >> >> >>Issue #5: Co-existence of PCN and ECN without use of tunnel >>=========================================================== >>Need to determine if this should be addressed by this draft. >> >> >>Issue #6: Use of PCN by multiple DiffServ Classes >>================================================= >>This can be added to the Intro section of this draft. >>But this discussion may be more appropriate in the Arch draft. >> >> >>Issue #7: ECMP considerations for PCN Encoding >>============================================== >>This should be one of the Encoding Option Evaluation Criteria. >>But may also want to add new subsections under each of the >>encoding choices on how they address this (and other) encoding >>option evaluation criterion. >> >> >>Issue #8: Document organization and text cleanup/addition >>========================================================= >>There are number of open issues relating to possible document >>organization changes and addition of new text (or clean up of >>existing text). One of them is expansion on tunneling's impact >>on encoding options. Fixes to typo should also be part of this. >> >> >> >> >>_______________________________________________ >>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 ____________________________________________________________________________ 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 Dec 04 13:02: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 1Izc5K-0001aK-Nk; Tue, 04 Dec 2007 13:01:30 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Izc5J-0001YN-Ap for pcn-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:01:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc5I-0001YE-UW for pcn@ietf.org; Tue, 04 Dec 2007 13:01:29 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izc5H-0008KC-R6 for pcn@ietf.org; Tue, 04 Dec 2007 13:01:28 -0500 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 18:01:32 +0000 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] PCN Encoding Comparison Draft Open Issues Date: Tue, 4 Dec 2007 18:01:32 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Encoding Comparison Draft Open Issues Thread-Index: Acg2GXCcwzMCI98CTkCyAJBdsnWETAAhQf73 References: <5.2.1.1.2.20071204011609.022d5750@pop3.jungle.bt.co.uk> From: To: , X-OriginalArrivalTime: 04 Dec 2007 18:01:32.0883 (UTC) FILETIME=[B411E230:01C8369F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 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 I reaalise we discounted the nonce anyway at the meeting yesterday but I = just thought I would add a bit... =20 AFAIK we were currently running with the assumption (in architecture = draft) that all nodes in the PCN domain are trusted. THis trust = assumption is explicitly mentioned in the initial charter as assumption = (A). That would leave the nonce purely being used as a test for errors = rather than as a test for accurate reporting as it is used in RFC3540. =20 Toby =20 ______________________________________________________________________ Toby Moncaster, Networks Research Centre, BT = Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 = 648734 ________________________________ From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] Sent: Tue 04/12/2007 01:59 To: Kwok-Ho Chan Cc: pcn@ietf.org Subject: Re: [PCN] PCN Encoding Comparison Draft Open Issues Kwok, Issue #3e Is(are) "nounce" encoding state(s) needed? Some background, then my opinion at the end... Validation of a nonce is typically done by taking the sum of all the = nonces between one feedback signal and the next. In general this requires identifiable checkpoints to start and end the calculation over all the intevening nonces. Therefore, between PCN boundary nodes, a nonce only works if the packets can be reliably identified and ordered in the same = way by the ingress and the egress. As PCN ingress nodes don't add sequence numbers or use existing sequence numbers and the egress doesn't read sequence numbers or correct any misordering, a nonce would not ever be ever able to be reliably = validated by the boundary nodes. The only possible need for the nonce is if ECN is also being used e2e, = and the endpoints validate the ECN nonce with their knowledge of packet = ordering. What would be the implication of re-using an ECN-nonce codepoint if the source did deploy the nonce? Let's imagine the PCN w-g decided to re-use one of the ECN nonce codepoints for (say) admission marking. If a source encoded a nonce into a packet stream but the PCN ingress overwrote the nonce codepoint to ensure it wasn't misinterpreted as (say) admission marking within the PCN domain, the source would think that something = along the path or the receiver was 'cheating' in some way. In RFC3540 it's up = to the source what to do in this case. It might stop sending if it thinks = the receiver is cheating. But nothing would break if the source decided to = just carry on even tho something might be cheating. However, a bad precedent would be set overloading a header codepoint without any negotiation = mechanism. RFC3540 (the ECN nonce) is experimental having attained that status in = Jun 03. It hasn't been implemented by anyone (yet), except one instance by = the main author which has not been deployed or made available as binary or = source. My tuppence worth would be that, if we decide to somehow use the ECN codepoints for PCN codepoints, there would be no problem also re-using = the ECN nonce for PCN codepoints. Ie, PCN can't use a nonce itself (because = of the re-ordering issues above). HTH Bob At 19:46 30/11/2007, Kwok-Ho Chan wrote: >If you have problem with the link to the Issues List, >You can use the link: >http://standards.nortel.com/pcn/PCN_Encoding_Comparison_Draft_OpenIssues= .txt > >Sorry for any inconvenience. >-- Kwok -- > >At 02:26 PM 11/30/2007, you wrote: >>The current open issues for: >>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-= 01.txt >>are documented at: >>http://standards.nortelnetworks.com/pcn/PCN_Encoding_Comparison_Draft_O= penIssues.txt >> >>This file will be updated based on discussions and resolutions of = these >>and additional >>open issues for the draft. >> >>Please review the draft and the issues list. >> >>E-Mail list discussions on the open issues should have: >>"EC Issue 03.c" as the start of the E-Mail subject field for >>"PCN Encoding Comparison Draft Issue 3 Sub-Issue a" >>to help multiple drafts, multiple issues, discussion management. >> >>Please let me know if you want any changes/corrections/additions to = this >>file. >>For example: the creation of a new issue, or sub-issue of an existing = issue. >> >>I have the content of the Issues List cut-and-pasted below in this = E-Mail. >>But will be using the file as the master copy going forward. >> >>Thank you very much for your time and attention to this work. >>-- Kwok -- >> >> >>Content of the PCN Encoding Comparison Draft Issues List file: >> >>Issues List for PCN Encoding Comparison Draft >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Updated: Nov 28, 2007 >>Editor: Kwok Ho Chan >>Draft: >>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-= 01.txt >> >>For further discussions, please use notations of: >>- EComp03.c is used to reference Encoding Comparison draft Issue = "03.c". >>- "chan-01" is used to reference version -01 of the personal draft. >> >> >>Issue #1: ECN Support in a PCN Domain >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D >>The resolution of this issue will clarify how a PCN Domain needs >>to treat ECN (RFC3168) packets, in terms of Interior Nodes and >>Edge Nodes. This issue arise with discussion on the Architecture >>draft, but this will definitely impact the PCN Encoding Comparison >>draft, with possible impact on the algorithm discussions. >>The resolution of this issue will also solidify the definition of >>a PCN Domain. >>The starting point will be: Does the use of DiffServ sufficiently >>define the logical boundaries of a PCN Domain? Logical because >>the same physical network device (router,switch,etc) may support >>a PCN Domain as well as some other non-PCN domains. >> >> >>Issue #2: Deletion of the Out of Band Channel Section >>=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=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 >>It have been proposed to remove chan-01 section 3.4 Out-of-Band >>Channel as Encoding Transport. This is considered to be out of scope >>for the WG. Would like some agreements on the list before removal. >> >> >>Issue #3: Encoding States >>=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 >>The Encoding States indicated in chan-01 section 2 Encoding = Requirements >>needs to be better defined and clarified. >>More specifically: >>a. Removing PCN Capable Transport Marking (Non-PCN Capable Transport >> Marking) as a notion of Encoding State, just indicate the need >> for this separation as a requirment (possibly in the = Architecture). >>b. Better explanation/indication of Single Marking for both Admission >> Marking and Termination Marking >>c. Possible additional encoding choices when DSCP+ECN fields are used. >>d. Which Encoding States should the WG require? >> Should there be optional Encoding States? >> And their deployment options. >>e. Is(are) "nounce" encoding state(s) needed? >> >> >>Issue #4: Encoding Option Evaluation Criteria >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Need to add a section that indicates and describes the encoding option >>evaluation criteria. May want to add OAM impacts/considerations here = or in >>some new section. >> >> >>Issue #5: Co-existence of PCN and ECN without use of tunnel >>=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=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=3D=3D=3D >>Need to determine if this should be addressed by this draft. >> >> >>Issue #6: Use of PCN by multiple DiffServ Classes >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>This can be added to the Intro section of this draft. >>But this discussion may be more appropriate in the Arch draft. >> >> >>Issue #7: ECMP considerations for PCN Encoding >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>This should be one of the Encoding Option Evaluation Criteria. >>But may also want to add new subsections under each of the >>encoding choices on how they address this (and other) encoding >>option evaluation criterion. >> >> >>Issue #8: Document organization and text cleanup/addition >>=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=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=3D >>There are number of open issues relating to possible document >>organization changes and addition of new text (or clean up of >>existing text). One of them is expansion on tunneling's impact >>on encoding options. Fixes to typo should also be part of this. >> >> >> >> >>_______________________________________________ >>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 _________________________________________________________________________= ___ 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 Tue Dec 04 14:11:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdBE-00039Y-MI; Tue, 04 Dec 2007 14:11:40 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IzdBC-00035L-IN for pcn-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdBB-00034H-NO for pcn@ietf.org; Tue, 04 Dec 2007 14:11:37 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdB7-00024Z-55 for pcn@ietf.org; Tue, 04 Dec 2007 14:11:37 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 19:11:38 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 19:11:38 +0000 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 1196795491154; Tue, 4 Dec 2007 19:11:31 +0000 Received: from mut.jungle.bt.co.uk ([10.73.176.226]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id lB4JAuhp004662; Tue, 4 Dec 2007 19:11:05 GMT Message-Id: <5.2.1.1.2.20071204190855.023a3380@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 04 Dec 2007 19:11:20 +0000 To: From: Bob Briscoe Subject: RE: [PCN] PCN Encoding Comparison Draft Open Issues In-Reply-To: References: <5.2.1.1.2.20071204011609.022d5750@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: 04 Dec 2007 19:11:38.0168 (UTC) FILETIME=[7E9D7380:01C836A9] X-Spam-Score: -1.0 (-) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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 Toby, Well, strictly, the charter says we should 'keep inter-domain in mind', so we certainly shouldn't assume trust when it comes to precluding future use of codepoints. But the previous point still holds - if we find a way to get the other ECN codepoints across a PCN domain, /another/ PCN nonce for use purely between the PCN edge nodes wouldn't work anyway. Bob At 18:01 04/12/2007, toby.moncaster@bt.com wrote: >I reaalise we discounted the nonce anyway at the meeting yesterday but I >just thought I would add a bit... > >AFAIK we were currently running with the assumption (in architecture >draft) that all nodes in the PCN domain are trusted. THis trust assumption >is explicitly mentioned in the initial charter as assumption (A). That >would leave the nonce purely being used as a test for errors rather than >as a test for accurate reporting as it is used in RFC3540. > >Toby > >______________________________________________________________________ >Toby Moncaster, Networks Research Centre, BT Research >B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734 > > >________________________________ > >From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >Sent: Tue 04/12/2007 01:59 >To: Kwok-Ho Chan >Cc: pcn@ietf.org >Subject: Re: [PCN] PCN Encoding Comparison Draft Open Issues > > > >Kwok, > >Issue #3e >Is(are) "nounce" encoding state(s) needed? > >Some background, then my opinion at the end... > >Validation of a nonce is typically done by taking the sum of all the nonces >between one feedback signal and the next. In general this requires >identifiable checkpoints to start and end the calculation over all the >intevening nonces. Therefore, between PCN boundary nodes, a nonce only >works if the packets can be reliably identified and ordered in the same way >by the ingress and the egress. > >As PCN ingress nodes don't add sequence numbers or use existing sequence >numbers and the egress doesn't read sequence numbers or correct any >misordering, a nonce would not ever be ever able to be reliably validated >by the boundary nodes. >The only possible need for the nonce is if ECN is also being used e2e, and >the endpoints validate the ECN nonce with their knowledge of packet ordering. > >What would be the implication of re-using an ECN-nonce codepoint if the >source did deploy the nonce? Let's imagine the PCN w-g decided to re-use >one of the ECN nonce codepoints for (say) admission marking. If a source >encoded a nonce into a packet stream but the PCN ingress overwrote the >nonce codepoint to ensure it wasn't misinterpreted as (say) admission >marking within the PCN domain, the source would think that something along >the path or the receiver was 'cheating' in some way. In RFC3540 it's up to >the source what to do in this case. It might stop sending if it thinks the >receiver is cheating. But nothing would break if the source decided to just >carry on even tho something might be cheating. However, a bad precedent >would be set overloading a header codepoint without any negotiation mechanism. > >RFC3540 (the ECN nonce) is experimental having attained that status in Jun >03. It hasn't been implemented by anyone (yet), except one instance by the >main author which has not been deployed or made available as binary or source. > >My tuppence worth would be that, if we decide to somehow use the ECN >codepoints for PCN codepoints, there would be no problem also re-using the >ECN nonce for PCN codepoints. Ie, PCN can't use a nonce itself (because of >the re-ordering issues above). > >HTH > > >Bob > >At 19:46 30/11/2007, Kwok-Ho Chan wrote: > >If you have problem with the link to the Issues List, > >You can use the link: > >http://standards.nortel.com/pcn/PCN_Encoding_Comparison_Draft_OpenIssues.txt > > > >Sorry for any inconvenience. > >-- Kwok -- > > > >At 02:26 PM 11/30/2007, you wrote: > >>The current open issues for: > >>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-0 > 1.txt > >>are documented at: > >>http://standards.nortelnetworks.com/pcn/PCN_Encoding_Comparison_Draft_Op > enIssues.txt > >> > >>This file will be updated based on discussions and resolutions of these > >>and additional > >>open issues for the draft. > >> > >>Please review the draft and the issues list. > >> > >>E-Mail list discussions on the open issues should have: > >>"EC Issue 03.c" as the start of the E-Mail subject field for > >>"PCN Encoding Comparison Draft Issue 3 Sub-Issue a" > >>to help multiple drafts, multiple issues, discussion management. > >> > >>Please let me know if you want any changes/corrections/additions to this > >>file. > >>For example: the creation of a new issue, or sub-issue of an existing > issue. > >> > >>I have the content of the Issues List cut-and-pasted below in this E-Mail. > >>But will be using the file as the master copy going forward. > >> > >>Thank you very much for your time and attention to this work. > >>-- Kwok -- > >> > >> > >>Content of the PCN Encoding Comparison Draft Issues List file: > >> > >>Issues List for PCN Encoding Comparison Draft > >>============================================= > >>Updated: Nov 28, 2007 > >>Editor: Kwok Ho Chan > >>Draft: > >>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-0 > 1.txt > >> > >>For further discussions, please use notations of: > >>- EComp03.c is used to reference Encoding Comparison draft Issue "03.c". > >>- "chan-01" is used to reference version -01 of the personal draft. > >> > >> > >>Issue #1: ECN Support in a PCN Domain > >>===================================== > >>The resolution of this issue will clarify how a PCN Domain needs > >>to treat ECN (RFC3168) packets, in terms of Interior Nodes and > >>Edge Nodes. This issue arise with discussion on the Architecture > >>draft, but this will definitely impact the PCN Encoding Comparison > >>draft, with possible impact on the algorithm discussions. > >>The resolution of this issue will also solidify the definition of > >>a PCN Domain. > >>The starting point will be: Does the use of DiffServ sufficiently > >>define the logical boundaries of a PCN Domain? Logical because > >>the same physical network device (router,switch,etc) may support > >>a PCN Domain as well as some other non-PCN domains. > >> > >> > >>Issue #2: Deletion of the Out of Band Channel Section > >>===================================================== > >>It have been proposed to remove chan-01 section 3.4 Out-of-Band > >>Channel as Encoding Transport. This is considered to be out of scope > >>for the WG. Would like some agreements on the list before removal. > >> > >> > >>Issue #3: Encoding States > >>========================= > >>The Encoding States indicated in chan-01 section 2 Encoding Requirements > >>needs to be better defined and clarified. > >>More specifically: > >>a. Removing PCN Capable Transport Marking (Non-PCN Capable Transport > >> Marking) as a notion of Encoding State, just indicate the need > >> for this separation as a requirment (possibly in the Architecture). > >>b. Better explanation/indication of Single Marking for both Admission > >> Marking and Termination Marking > >>c. Possible additional encoding choices when DSCP+ECN fields are used. > >>d. Which Encoding States should the WG require? > >> Should there be optional Encoding States? > >> And their deployment options. > >>e. Is(are) "nounce" encoding state(s) needed? > >> > >> > >>Issue #4: Encoding Option Evaluation Criteria > >>============================================= > >>Need to add a section that indicates and describes the encoding option > >>evaluation criteria. May want to add OAM impacts/considerations here or in > >>some new section. > >> > >> > >>Issue #5: Co-existence of PCN and ECN without use of tunnel > >>=========================================================== > >>Need to determine if this should be addressed by this draft. > >> > >> > >>Issue #6: Use of PCN by multiple DiffServ Classes > >>================================================= > >>This can be added to the Intro section of this draft. > >>But this discussion may be more appropriate in the Arch draft. > >> > >> > >>Issue #7: ECMP considerations for PCN Encoding > >>============================================== > >>This should be one of the Encoding Option Evaluation Criteria. > >>But may also want to add new subsections under each of the > >>encoding choices on how they address this (and other) encoding > >>option evaluation criterion. > >> > >> > >>Issue #8: Document organization and text cleanup/addition > >>========================================================= > >>There are number of open issues relating to possible document > >>organization changes and addition of new text (or clean up of > >>existing text). One of them is expansion on tunneling's impact > >>on encoding options. Fixes to typo should also be part of this. > >> > >> > >> > >> > >>_______________________________________________ > >>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 > >____________________________________________________________________________ >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 ____________________________________________________________________________ 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 Dec 04 20:10: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 1Izimb-00085U-48; Tue, 04 Dec 2007 20:10:37 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IzimZ-000824-Ja for pcn-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 20:10:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzimY-0007zt-P7 for pcn@ietf.org; Tue, 04 Dec 2007 20:10:34 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzimY-0000DD-7u for pcn@ietf.org; Tue, 04 Dec 2007 20:10:34 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB51AW717013 for ; Wed, 5 Dec 2007 01:10:32 GMT Received: from KCHAN-2K3.nortel.com ([47.130.25.102] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 20:10:01 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Dec 2007 17:09:48 -0800 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Dec 2007 01:10:01.0565 (UTC) FILETIME=[8FA370D0:01C836DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [PCN] "Hallway" Meeting on Algorithms 9-11 AM Wed Dec 5, 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 Hi all: The algorithm drafts authors had been having many hallway/dining-room/where-ever meetings in many IETF meetings so far. We are continuing to have these meetings here in Vancouver. But we feel that we want to open this up and invite all interested people to join us. Please notice this is just a "hallway" get together of interested people, not an official IETF meeting, And its purpose is to share information and discussions. We will be meeting: Date: Wednesday Dec 5, 2007 Time: 9 - 11 AM Place: IETF Registration Desk area to meet and go somewhere The plan is we will go to one of the not-used rooms or use a corner of an area and hold this meeting (as how many "hallway" meetings happens). After we settle into a room/area, we will post a message on the IETF message board indicating where we are. Please check the IETF message board if you don't see us at the IETF Registration Desk area. The planned agenda: - Introduce information on Algorithm Comparison. - Provide new results on Algorithm simulations, investigations, studies - Exchange ideas on the Algorithm topic. Sorry for the late notice on this. Hope the interested people can join us. Thanks! -- Kwok and Authors of the Algorithm drafts -- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 05 14:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J00OO-0008DA-NO; Wed, 05 Dec 2007 14:58:48 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J00ON-0008Cj-Bv for pcn-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 14:58:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J00ON-0008C5-1n for pcn@ietf.org; Wed, 05 Dec 2007 14:58:47 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J00OM-0004iz-Jd for pcn@ietf.org; Wed, 05 Dec 2007 14:58:47 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB5Jwi712436 for ; Wed, 5 Dec 2007 19:58:44 GMT Received: from KCHAN-2K3.nortel.com ([47.130.18.192] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:57:25 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Dec 2007 11:57:20 -0800 To: pcn@ietf.org From: "Kwok-Ho Chan" Subject: Re: [PCN] "Hallway" Meeting on Algorithms 9-11 AM Wed Dec 5, 2007 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Dec 2007 19:57:26.0032 (UTC) FILETIME=[0EE1F900:01C83779] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 We held this meeting at 9 - 11:30 AM today (Wed 12/5/07). We have not complete all the simulation discussions. We will continue our "Hallway" Discussion today (Wed 12/5/07) at 5 PM, meeting at the IETF Registration Desk and find a place to do our discussion. I will post on the IETF Message Board the location where we are doing our discussion after we settle down at that location. Thanks! -- Kwok -- At 05:09 PM 12/4/2007, Kwok-Ho Chan wrote: >Hi all: >The algorithm drafts authors had been having many >hallway/dining-room/where-ever >meetings in many IETF meetings so far. We are continuing to have >these meetings >here in Vancouver. But we feel that we want to open this up and >invite all interested >people to join us. > >Please notice this is just a "hallway" get together of interested >people, not an official >IETF meeting, And its purpose is to share information and discussions. > >We will be meeting: >Date: Wednesday Dec 5, 2007 >Time: 9 - 11 AM >Place: IETF Registration Desk area to meet and go somewhere > >The plan is we will go to one of the not-used rooms or use a corner >of an area and >hold this meeting (as how many "hallway" meetings happens). > >After we settle into a room/area, we will post a message on the IETF >message board >indicating where we are. Please check the IETF message board if you don't see >us at the IETF Registration Desk area. > >The planned agenda: >- Introduce information on Algorithm Comparison. >- Provide new results on Algorithm simulations, investigations, studies >- Exchange ideas on the Algorithm topic. > >Sorry for the late notice on this. Hope the interested people can join us. >Thanks! >-- Kwok and Authors of the Algorithm drafts -- > > > >_______________________________________________ >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 Dec 06 11:35: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 1J0JgA-0005um-LN; Thu, 06 Dec 2007 11:34:26 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J06CK-0002M3-JY for pcn-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:10:44 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J06CK-0002Lt-9v for pcn@ietf.org; Wed, 05 Dec 2007 21:10:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05zv-0001yO-TO; Wed, 05 Dec 2007 20:57:55 -0500 Received: from fmmailgate04.web.de ([217.72.192.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J05zu-0005NS-F2; Wed, 05 Dec 2007 20:57:55 -0500 Received: from web.de by fmmailgate04.web.de (Postfix) with SMTP id 677683F83CAC; Thu, 6 Dec 2007 02:57:53 +0100 (CET) Received: from [130.129.86.56] by freemailng0705.web.de with HTTP; Thu, 06 Dec 2007 02:57:52 +0100 Date: Thu, 06 Dec 2007 02:57:52 +0100 Message-Id: <1538917434@web.de> MIME-Version: 1.0 From: Michael.Menth@web.de To: michael.menth@gmx.de, pcn@ietf.org, rtgwg@ietf.org Precedence: fm-user Organization: http://freemail.web.de/ X-Provags-Id: V01U2FsdGVkX1/J6PiNfhvC8yK7ortovV0/dW0ph2lY8+IBWlXz3iABOM9iW tAgFEE4vl1vPEwOI6Qa9MYIiLCdjkzdYtQppv5F8NRf/6N2NfctWc848AQl9 w== Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-TMDA-Confirmed: Wed, 05 Dec 2007 21:10:44 -0500 X-Mailman-Approved-At: Thu, 06 Dec 2007 11:34:25 -0500 Cc: Subject: [PCN] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi folks, I'm here at IETF and you might want to reach me via Email, but my email seems be broken. Therefore, I cannot receive your emails, nor those from the lists. If you want to reach me here in Vancouver, please use my email above! Regards, Michael _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 10 10:03: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 1J1kAm-0007w6-84; Mon, 10 Dec 2007 10:03:56 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J1kAl-0007w1-Iq for pcn-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 10:03:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kAl-0007vs-7n for pcn@ietf.org; Mon, 10 Dec 2007 10:03:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1kAk-0005ze-Op for pcn@ietf.org; Mon, 10 Dec 2007 10:03:55 -0500 X-IronPort-AV: E=Sophos;i="4.23,276,1194217200"; d="scan'208";a="477501" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2007 16:03:50 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBAF3rGn003220 for ; Mon, 10 Dec 2007 16:03:53 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBAF3cnG018580 for ; Mon, 10 Dec 2007 15:03:53 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 16:03:52 +0100 Received: from [10.0.0.31] ([10.61.81.243]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 16:03:52 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Mon, 10 Dec 2007 16:03:48 +0100 To: PCN IETF X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Dec 2007 15:03:52.0326 (UTC) FILETIME=[E05C7A60:01C83B3D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2363; t=1197299033; x=1198163033; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Few=20suggestions/comments=20on=20draft-charny- pcn-comparison |Sender:=20; bh=m+cS0drwd429CdOLMwTTFULkhNboVNgvGkw6lFQR33Y=; b=Yrc1Rif6U7nNeBoT1wnMajpEiVxNztvhnHKWg/JHaQadqBc9gpB4l0+pa+ 91RcHGAdOjLgdoGs82+7JdKK0Ap8T0oV2wHBU5lv38ZI/1y71SBYAxLaKWqp Tk3YMlx/fL; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [PCN] Few suggestions/comments on draft-charny-pcn-comparison 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 Hello, A few suggestions/comments (from a quick read): * I found sections 1-10 of this document very helpful to try get my head around the various approaches in a consistent/comprehensive manner. I hope this document continues to be progressed. * While I understand the document does not (yet) try to weigh the different "comparison Criteria", I think it would be worth pointing out a few salient points like: (i) when discussing/comparing the "type of metering & marking": it may be worth pointing out that "Excess-rate-marking" is a very common mechanism supported on many (if not all) modern router Hardware today, while any other metering/marking flavor is probably not so commonly supported today. This seems like a significant consideration with respect to possible PCN introduction. (ii) when discussing/comparing the "rate measurement at boundary nodes": it may be worth pointing out that a scheme that does NOT require "rate measurement at boundary nodes" would result in considerable simplification. (iii) when discussing "parameter configuration", the I-D only discusses the "network-wide" parameters (that are only applicable to SM). Thus, it kind-of suggests that SM may be a little more complex to configure than the other schemes. However, the I-D omits to discuss all the other parameters that are likely to be much much harder to fine-tune (probably making the configuration of the single SM network-wide parameter appear as piece of cake). Those other parameters should also be discussed. * when discussing 3SM (in section 4.3 and section 9), it would be very useful to characterize 3SM performance WITH and WITHOUT rate measurement at boundary node. As stated above, if the 3SM scheme works well without rate measurement at boundary node, that would be a significant benefit of that scheme. However, when used without rate measurement at boundary node, one would expect performance degradation (depending on actual scheme this may include under- admission and/or high signaling). I think it is the intention of the authors to include material on this in future versions. I am looking forward to such information helping further assess whether 3SM without rate measurement is a viable option. I hope this is useful. Francois _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 10 12:54: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 1J1mpk-0007Xd-NB; Mon, 10 Dec 2007 12:54:24 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J1mpj-0007Ra-1j for pcn-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 12:54:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mpi-0007QK-Nm for pcn@ietf.org; Mon, 10 Dec 2007 12:54:22 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1mpg-0007Em-Kl for pcn@ietf.org; Mon, 10 Dec 2007 12:54:22 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lBAHsK3B000660 for ; Mon, 10 Dec 2007 11:54:20 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 11:54:19 -0600 Received: from [147.117.169.80] ([147.117.169.80]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 11:54:19 -0600 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-BFHjFx8ROGeVFgUbNj3g" Organization: Ericsson IP Infrastructure Date: Mon, 10 Dec 2007 12:54:18 -0500 Message-Id: <1197309258.7392.21.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) X-OriginalArrivalTime: 10 Dec 2007 17:54:19.0635 (UTC) FILETIME=[B04FFC30:01C83B55] X-Spam-Score: -4.0 (----) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Subject: [PCN] IETF 70 PCN 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 --=-BFHjFx8ROGeVFgUbNj3g Content-Type: text/plain Content-Transfer-Encoding: 7bit PCN, Here are the draft minutes from last Monday's meeting. Thanks to Tom Taylor for recording them! There are a few holes, so please review them carefully and send comments/corrections to the list. The chairs will be confirming some of the decisions made in the meeting on the mailing list this week. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-BFHjFx8ROGeVFgUbNj3g Content-Disposition: attachment; filename=pcn-ietf70-minutes.draft.txt Content-Type: text/plain; name=pcn-ietf70-minutes.draft.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion and Pre-Congestion Notification WG (pcn) IETF 70 -- **DRAFT** Meeting Minutes Monday, December 3, 2007 Vancouver, BC, Canada 1740-1950 Afternoon Session III Salon 2 ==================================== CHAIRs: Scott Bradner Steven Blake Minute taker: Tom Taylor AGENDA: o Administrivia chairs 10 min ------------------------------------------------------------------------------ - Blue sheets - Scribe - Agenda bash - Milestones status Steven presented on the working group status. Sees open issues on architecture doc -- not yet ready for WGLC. Need document for second milestone. Want one marking and encoding solution. Reviewed premises of work ("Why we are here") Chairs' assessment: get off the corner cases. Want single solutions particularly in the interior, to prevent interoperability nightmares. We have previously interpreted "inelastic flows" too narrowly. Need to be compatible with ECN and Diffserv. Need to speed things up. Operator feedback: moving in right direction, don't use too many IP header codepoints, hurry up so we can look at multi-domain Comments: Anna: Have to be careful not to jeopardize multi-domain solutions. Scott: can't know everything. Keep interior marking simple, leave innovation to the edges is a proposal toward long-term validity. o Discuss open issues in draft-ietf-pcn-architecture-02 all 75 min ------------------------------------------------------------------------------ Philip: summary of progress and open issues. Joe: doesn't understand scenario where tunnel terminates within a PCN domain. Philip: more general scenario of tunnel into Diffserv domain. Joe: would we not use same protective mechanism as for Diffserv. Philip: basically same mechanism, but needed a little adaptation. Joe: but seems more reasonable to do at edge. Steven: RFC has tunnel end treated as ingress point to network. Michael M.: don't worry about this unless operators say it matters. Scott agrees. Tina: probing should be based on single message, signalling reqts dealt with in a separate draft. Steven: Probing advocated for two situations, ECMP and small aggregates. Small-aggregate reason is in his view a corner case. ECMP is interesting. Would be nice to have simple solution to that problem. Lot of security issues to probing. Imposing special reqts on router not a great way to go. AS Chair: this is where we make the decision. Michael: RSVP Scott: is there an RFC on ho to do do this? Magnus: Francisco: Two drafts coming out. PCN is a different problem from the general RSVP problem. Michael: RSVP could be used to trigger admission. Anna: security one issue. Applicability of RSVP another. Issue on list was whether RSVP gives right info for ECMP case. Steven: certainly deployments where RSVP supported on ingress and egress, could then do PATH, RSVP use of PCN markings. Not in scope of PCN itself. Xiaoming: option packages dangerous for inter-domain. Elwyn (IAB view): concerned with time required to do admission control if you probe. Beginning to have serious issues with connection delay. Also concerned about trying to make external decisions on what happens on a single link. Bob: BT analyses show will get same result for repeated probes -- get time correlation, so single probe enough. Elwyn: even first probe raises issue of connection delay. Bob: in some cases can probe in parallel to signalling. Lars: what do you do with the remaining packets of a data flow that arrive while you are deciding to admit? Another issue, what impact does probing have on overall architecture. Jozef: UDP -- no feedback. (Questioned by ADs) Anna: is this a binary decision? Lars: any other way to handle ECMP? Bob: in some scenarios, don't need probing -- e.g. MPLS Anna: Steven: inconsistent to assume operator is competent to use PCN but not competent to engineer ECMP correctly. Steven: also have to think about reverse path with probing. Philip: BT has been thinking about ECMP for a while, but has failed to come up with an elegant solution. Can't predict that such a solution will emerge in next 6 months. Lars: would like to proceed without, see if any operator says it's critical. Anna: ECMP problems likely to be fixed independently. Steven as Chair: Egress discovery - is there any scenario where probing is the only way to do it? No answer. How many think we need to work on probing? ??: should be hashing Michael: not important to work on probing now, but should keep aware to allow extensibility. Scott: what needs to be in the architecture doc? How many people think we need a discussion of probing in the arch document? Kwok-Ho: question on RSVP -answered. Francisco: simplicity means lowered usefulness. Jozef: matter of deployment scope whether probing should be discussed. Scott: this is an overall arch doc, what level of discussion called for Jozef: reasons for probing, not solutions ??: optional component of arch Anna: is current discussion OK? Steven: does there need to be discussion? A number of "yes". How many find current discussion necessary and sufficient? Again a number of "yes". Finds a significant number of people supporting this latter view. How many think protocol work on probing should be done right now? No one. Lars: how many think it should be done before arch draft WGLC? No one. Centralized decision-making node: Steven: is this something we need to work on? Anna: two questions -- should it be mentioned, should WG work on it? Discussion: differing views. Recognition that centralized node does not ncessarily mean new protocol. Steven: consensus that current text is sufficient on the topic. Addressing issue -- peer discovery. Philip enumerates a number of alternatives, will expand text. ECN Bob spoke in favour of classifying ECN as non-PCN Magnus: prefers ECN-compatible solution Michael: two different behaviours Discussion of whether all routers in the domain are PCN-capable. Jozef finds that unrealistic. Lars: charter assumption. Scott: matters only for routers that will experience congestion. Lars: scenario where e2e ECN would be beneficial would also be one where PPCN can help Magnus: Anna: discussion should really be informed by outcome of encoding discussion Steven: some algorithms would Lars: prefers coexistence Bob: endpoint based measurement doesn't work in some cases Magnus: trying to run below application level Steven: need more work in arch draft on ECN. Let discussion continue on list. Maybe encoding comparison will provide guidance. Philip: this is the last issue, as he sees it. Any other views? No reply. o Discuss open issues in draft-chan-pcn-encoding-comparison-01 all 45 min ------------------------------------------------------------------------------ Kwok-Ho presenting. Series of questions to simplify draft. Bob: can't see how PCN would work w/o using Diffserv codepoints. Steven: assumed that Diffserv would be used Jozef: redefine RFC 3168? Lars: really problematic. Jozef: suggested possibility: redefine behaviour of DSCP codepoint Kwok-Ho: bottom line: WG would register new DSCP codepoint with IANA. Scott: Diffserv codepoint assignments are based on Standards Track actions. Bob: thought Diffserv used locally-defined values. Anna: answered questions on slide. First two bullets, yes. Bob: trying to clarify intent of questions. Noted that whether Diffserv codepoint is used is different question from whether new codepoint should be standardized. Bob: on second bullet, replace 3.2 with para or two on how it would be impossible to do without Diffserv. Kwok-Ho: third bullet -- can out-of-band channels be eliminated from further consideration? Anna and Scott: rather than throw it away, say it will not be considered. Next chart: what indications are required. Drop Nonce indication. Agreed. Jozef: Anna: identify states. Steven: can't see fewer than three markings needed, or more than four. Philip: spoke for transition indications ??: Steven as contributor: have the draft concentrate on encodings -- where do we get the bits from? Other work can provide semantics. Discussion of whether DSCP visible end-to-end -- battle in Diffserv -- customers vs. operators. Philip: Need to say that range of states required is 3 to 5. Agreed. Next chart: criteria: Leakage-safe could be an additional criterion -- RFC 4744 Timed out. Take question of whether this is WG item to the list. --=-BFHjFx8ROGeVFgUbNj3g 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 --=-BFHjFx8ROGeVFgUbNj3g-- From pcn-bounces@ietf.org Mon Dec 10 13:35: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 1J1nTi-0007ty-U4; Mon, 10 Dec 2007 13:35:42 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J1nTi-0007pV-D2 for pcn-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 13:35:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nTi-0007o6-1c for pcn@ietf.org; Mon, 10 Dec 2007 13:35:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1nTh-0003S7-I5 for pcn@ietf.org; Mon, 10 Dec 2007 13:35:41 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 10 Dec 2007 10:35:40 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBAIZe54007810 for ; Mon, 10 Dec 2007 10:35:40 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBAIZeCF025186 for ; Mon, 10 Dec 2007 18:35:40 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 13:35:33 -0500 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] Few suggestions/comments on draft-charny-pcn-comparison Date: Mon, 10 Dec 2007 13:35:33 -0500 Message-ID: In-Reply-To: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Few suggestions/comments on draft-charny-pcn-comparison Thread-Index: Acg7PelUn/jtxQq1Qkyf4AO9mVLF8wADlfBw From: "Anna Charny (acharny)" To: "Francois Le Faucheur (flefauch)" , "PCN IETF" X-OriginalArrivalTime: 10 Dec 2007 18:35:33.0399 (UTC) FILETIME=[72CA6A70:01C83B5B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3140; t=1197311741; x=1198175741; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Few=20suggestions/comments=20on =20draft-charny-pcn-comparison |Sender:=20; bh=YcxNjPeOMBBMQfEnYyUtK9zzEbFt5dRV//bKzrf0di4=; b=S1lnom+AzywtyVvULXFWu+MGchankKr3S6RgBf7EylNLeY/+ilQhCOBJl5 TpeO2oYf2RQqAbTQ/PruAWODuHOD9aI1NYWvxhdmTgG4wJyVuHbOibMqWZoo z8v0woYoji; Authentication-Results: sj-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Francois, Thank you for the comments. All makes perfect sense. =20 Will try to address in the next version of the draft - although some of the performance evaluation questions probably reside with simulation effort drafts...=20 Anna=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch)=20 > Sent: Monday, December 10, 2007 10:04 AM > To: PCN IETF > Subject: [PCN] Few suggestions/comments on draft-charny-pcn-comparison >=20 > Hello, >=20 > A few suggestions/comments (from a quick read): >=20 > * I found sections 1-10 of this document very helpful=20 > to try get my head around the various approaches in a=20 > consistent/comprehensive manner. I hope this document=20 > continues to be progressed. >=20 > * While I understand the document does not (yet) try to=20 > weigh the different "comparison Criteria", I think it would=20 > be worth pointing out a few salient points like: > (i) when discussing/comparing the "type=20 > of metering & marking": it may be worth pointing out that=20 > "Excess-rate-marking" is a very common mechanism supported on=20 > many (if not all) modern router Hardware today, while any=20 > other metering/marking flavor is probably not so commonly=20 > supported today. This seems like a significant consideration=20 > with respect to possible PCN introduction. > (ii) when discussing/comparing the=20 > "rate measurement at boundary > nodes": it may be worth pointing out that a scheme that does=20 > NOT require "rate measurement at boundary nodes" would result=20 > in considerable simplification. > (iii) when discussing "parameter=20 > configuration", the I-D only discusses the "network-wide"=20 > parameters (that are only applicable to SM). Thus, it kind-of=20 > suggests that SM may be a little more complex to configure=20 > than the other schemes. However, the I-D omits to discuss all=20 > the other parameters that are likely to be much much harder=20 > to fine-tune (probably making the configuration of the single=20 > SM network-wide parameter appear as piece of cake). Those=20 > other parameters should also be discussed. >=20 > * when discussing 3SM (in section 4.3 and section 9),=20 > it would be very useful to characterize 3SM performance WITH=20 > and WITHOUT rate measurement at boundary node. As stated=20 > above, if the 3SM scheme works well without rate measurement=20 > at boundary node, that would be a significant benefit of that=20 > scheme. However, when used without rate measurement at=20 > boundary node, one would expect performance degradation=20 > (depending on actual scheme this may include under- admission=20 > and/or high signaling). I think it is the intention of the=20 > authors to include material on this in future versions. I am=20 > looking forward to such information helping further assess=20 > whether 3SM without rate measurement is a viable option. >=20 > I hope this is useful. >=20 > Francois >=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 Tue Dec 11 13:27: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 1J29or-0004pX-UR; Tue, 11 Dec 2007 13:27:01 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J29oq-0004pO-4M for pcn-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 13:27:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29op-0004pG-Qz for pcn@ietf.org; Tue, 11 Dec 2007 13:26:59 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J29on-0006jE-Kf for pcn@ietf.org; Tue, 11 Dec 2007 13:26:59 -0500 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 lBBIQuHC030670 for ; Tue, 11 Dec 2007 12:26:56 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 12:26:56 -0600 Received: from [147.117.169.80] ([147.117.169.80]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 12:26:56 -0600 From: Steven Blake To: pcn Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 11 Dec 2007 13:26:55 -0500 Message-Id: <1197397615.21366.38.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 18:26:56.0692 (UTC) FILETIME=[6938EF40:01C83C23] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [PCN] Questions 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: , Errors-To: pcn-bounces@ietf.org During last week's meeting there was some discussion regarding the role of probing in PCN (see the preliminary minutes): 1. Does there need to be any discussion of probing in the architecture draft? 2. If yes to (1), is the current text in the architecture draft essentially correct and sufficient? 3. Does the working group need to do protocol work on probing prior to last call for the architecture draft? By the judgement of the chairs, the consensus of the room for each question was 1 - Yes, 2 - Yes, 3 - No (and these weren't close calls). We are opening these questions for discussion on the list. Please review the architecture draft -02 (especially Sec. 7) and send your feedback to the list. Regards, Scott & Steve =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Dec 11 15:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BHe-0000KI-TQ; Tue, 11 Dec 2007 15:00:50 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2BHd-0000K6-9l for pcn-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 15:00:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BHc-0000Jx-Ue for pcn@ietf.org; Tue, 11 Dec 2007 15:00:48 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2BHb-0000V0-Hg for pcn@ietf.org; Tue, 11 Dec 2007 15:00:48 -0500 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 lBBJxwpx027607 for ; Tue, 11 Dec 2007 14:00:46 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:00:35 -0600 Received: from [147.117.169.80] ([147.117.169.80]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:00:35 -0600 From: Steven Blake To: pcn Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 11 Dec 2007 15:00:34 -0500 Message-Id: <1197403234.21366.47.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 20:00:35.0384 (UTC) FILETIME=[7E394B80:01C83C30] X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [PCN] Questions on centralised control nodes 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 During last week's meeting there was some discussion regarding the role of centralised control nodes in PCN (see the preliminary minutes): 1. Does there need to be any discussion of centralized decision nodes in the architecture draft? 2. If yes to (1), is the current text in the architecture draft sufficient? By the judgement of the chairs, the consensus of the room for each question was 1 - Yes, 2 - Yes. We are opening these questions for discussion on the list. Please review the architecture draft -02 and send your feedback to the list. Regards, Scott & Steve =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Dec 11 17:04: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 1J2DD6-0003ZA-Bq; Tue, 11 Dec 2007 17:04:16 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2DD5-0003U4-8d for pcn-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 17:04:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DD4-0003Tw-S0 for pcn@ietf.org; Tue, 11 Dec 2007 17:04:14 -0500 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 1J2DD3-0001nj-So for pcn@ietf.org; Tue, 11 Dec 2007 17:04:14 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id EA034C0DD for ; Tue, 11 Dec 2007 23:04:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DCB67FFF9 for ; Tue, 11 Dec 2007 23:04:12 +0100 (CET) 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 B2275C0DD for ; Tue, 11 Dec 2007 23:04:12 +0100 (CET) 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 lBBM4CI09000 for ; Tue, 11 Dec 2007 23:04:12 +0100 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 2CB886F591 for ; Tue, 11 Dec 2007 22:56:12 +0100 (CET) Message-ID: <475F09D2.9030804@informatik.uni-wuerzburg.de> Date: Tue, 11 Dec 2007 23:06:10 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pcn 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: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [PCN] A two-layer approach for PCN 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 all, during last week's meeting I had discussions with many people regarding a separation of packet marking vs. admission control and flow termination aspects. The intention was to make the structure of PCN more obvious and to facilitate its adaptation to various network architectures. The following text reflects the outcome of these discussions. Comments are welcome. Regards, Michael -- The pre-congestion notification (PCN) architecture consists of two different layers: the packet marking layer (PML) and the admission control and flow termination layer (ACFTL). The packet marking layer (PML) describes how PCN-capable interior nodes meter and mark PCN packets. Within a single network only one packet marking layer (PML) MUST be deployed, i.e. PCN-capable interior nodes MUST implement the same metering and marking behavior for all links. The admission control and flow termination layer (ACFTL) describes how PCN edge nodes make use of the packet markings observed by the PCN egress node to decide whether new flows can be accepted or whether already admitted flows need to be terminated. The implementation of the admission control and flow termination layer (ACFTL) may take advantage of specific transport architectures and may be tailored for various signaling architectures with which it needs to interoperate. In contrast to the packet marking layer (PML), different instances admission control and flow termination layers (ACFTL) MAY be used in the same network as long as they interpret the semantics of the packet markings in the same way and don't lead to unfairness issues. +---+---+---+---+ | A | A | . | A | | C | C | . | C | | F | F | . | F | | T | T | . | T | | L | L | . | L | | | | | | | 0 | 1 | . | n | +---+---+---+---+ | PML | +---------------+ Figure 1: Within a single network, only one packet marking layer (PML) MUST be deployed, but several admission control and flow termination layers (ACFTL) MAY coexist. In the following, the concepts of the packet marking layer (PML) and admission control and flow termination layer (ACFTL) are briefly illustrated. 4 examples of mutually exclusive interior node behaviors for implementation of the PML: a) Ramp marking based on the admissible rate and excess-rate marking based on the supportable rate (CL proposal) b) Threshold marking based on the admissible rate and excess-rate marking with marking frequency reduction based on the supportable rate (3sm proposal) c) Threshold marking based on the admissible rate and excess-rate marking based on the supportable rate (behavioral intersection of CL and 3sm proposal) d) Excess rate marking based on the admissible rate (Single Marking proposal) Note that only one packet marking layer (PML) can be deployed within a single network. 3 examples for different edge node behaviors for implementation of the admission control and flow termination layer (ACFTL) based on the packet marking layer b) above: o E3Tunnel Given: edge-to-edge MPLS tunnels; Egress node measures CLE for tunnel and depending on that value, it sends an "admission-stop" or "admission-continue" message to the corresponding ingress node that then stops or continues admitting further flows. Flows are terminated when one of its packets was ET-marked. o End2PS Given: end-to-end on-path signalling protocol; PCN egress node is a RSVP capable node and returns PATHERR if first PATH msg was "admission-stop" marked; PCN ingress node accepts all flows whose RESV messages come through. Flows are terminated when one of its packets was ET-marked: the PCN egress node sends a RESVTEAR message to the PCN ingress. o Centralized node Given: centralized node (CN) in charge of admitting or terminating flows; Upon a new flow arrival, the CN issues an admission request to PCN ingress node for a future data flow with an indicated source-destination tuple; CN sends a probe packet to the PCN egress node which returns the probe to the CN; the CN rejects the flow if probe was marked and admits it if probe was unmarked. Flows are terminated when one of its packets was ET-marked. The PCN egress node sends the marked packet to the CN which terminated the corresponding flow. These admission control and flow termination layers (ACFTL) MAY simultaneously be applied in the same network. Similar methods can be defined based on the other packet marking layers (PML) defined above. Within the current charter, only one packet marking layer (PML) should be standardized as well as only one admission control and flow termination layer (ACFTL), presumably for ingress-egress aggregates. However, it is desirable that the architecture is extensible towards other admission control and flow termination layers (ACFTL) to address the need of various network architectures (e.g., without explicit aggregates, with multipath routing, with centralized control nodes, ...) that need QoS support in the future. Note: this text does not contradict the current version of the architecture draft. Essentially, the packet marking behavior of interior nodes is put into a packet marking layer and the admission control and flow termination behavior of edge nodes is put into an admission control and flow termination layer. The two-layer approach just makes the idea more explicit that different edge node behaviors may be defined for a single interior node behavior and that several edge node behaviors may coexist in the same network if necessary. -- 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 Dec 12 02:57: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 1J2MSw-0006gt-8M; Wed, 12 Dec 2007 02:57:14 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2MSu-0006gd-JH for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 02:57:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2MSo-0006gP-Gl for pcn@ietf.org; Wed, 12 Dec 2007 02:57:06 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2MSn-00085e-Q3 for pcn@ietf.org; Wed, 12 Dec 2007 02:57:06 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 12 Dec 2007 08:57:03 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Dec 2007 08:57:02 +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] Questions on probing Date: Wed, 12 Dec 2007 08:57:02 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C1625@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1197397615.21366.38.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing Thread-Index: Acg8I3dt8tgYDbcSR660DmqjIYiYYQAb4FZw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 12 Dec 2007 07:57:02.0951 (UTC) FILETIME=[94CF7770:01C83C94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Steve, generally I share the view of the room. I think the text in the architecture-02 is still focused to much on an expectation that probing is a regular requirement. I've commented on that earlier and attach my comments again below. If agreement is to progress the architecture without further discussion on probing, I can accept that. Regards, Rudiger Comments in line. |During last week's meeting there was some discussion regarding the role |of probing in PCN (see the preliminary minutes): | |1. Does there need to be any discussion of probing in the architecture | draft? Yes. |2. If yes to (1), is the current text in the architecture draft | essentially correct and sufficient? My general take on the probing disussion: Leave just section '7.1=20 Introduction' in the architecture and refer to another document=20 for a detailed discussion. Alternatively, move 7.2 and 7.3 to=20 the annex of the architecture doc. |3. Does the working group need to do protocol work on probing prior to | last call for the architecture draft? No. Detailed comments: 7.1. Introduction (to probing) 2nd paragraph, last sentence "This risk could be lessened by configuring on each link=20 sufficient 'safety margin' above the PCN-lower-rate." Please add: "Further, the decision could be based on whether any of=20 the boundary nodes involved in admission of the new flow on the unused aggregate is aware of pre-congestion for any of his already admitted aggregates. If there is no=20 pre-congestion, the flow can be admitted with little=20 risk. " I prefer to be explicit here, as I don't think the options=20 are just "being optimistic" or "probing". ------------------------------------------------------------ 3rd paragraph "The PCN-ingress-node explicitly determines, before admitting the prospective new flow, whether the ingress-egress- aggregate can support it." I'd suggest to add: "If necessary, the PCN-ingress-node...." I don't completely object to probing as long as I'm not sure=20 that all options avoiding it have been explored. I'd like to make sure that it is a "last resort". That's why I prefer to have the statements on probing to be less "binary", just=20 leaving you with an on/off decision.=20 ------------------------------------------------------------- 7.2. Probing functions Please change first bullet point to: " Make decision that probing is needed. As described above,=20 this is when the ingress-egress-aggregate or the ECMP path=20 is likely to carry no PCN-traffic." ^^^^^^^^^^^^^^^^^^ -------------------------------------------------------------- 2nd bullet point Please change to: " (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that=20 probing is needed (or the other way around). ^^^^^^^^^^^^^^^^^^^^^^^^^^ The ingress could also indicate that probing is required and=20 will start to the egress. -------------------------------------------------------------- 7.3. Discussion of rationale for probing, its downsides=20 and open issues I don't agree to the negative statement on the PCN coloured=20 signaling messages (mentioned in third viewpoint). Given that an ECMP algorithm is limited to evaluate addresses, PCN=20 coloured per flow signaling messages are good means to avoid=20 unnecessary termination of admitted flows. The signalling=20 packet is received with a congestion mark, and the new flow=20 is blocked. This method solves downside issues of the other=20 two viewpoints - it is just a single packet transmitted via=20 a link approaching the upper rate. So it is unlikly that it=20 causes admitted flows to be terminated. Note that I don't regard this as probing, as the signaling=20 message is transmitted anyway. --------------------------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 12 02:59: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 1J2MV3-0000wg-14; Wed, 12 Dec 2007 02:59:25 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2MV2-0000wb-AG for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 02:59:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2MV1-0000wT-Va for pcn@ietf.org; Wed, 12 Dec 2007 02:59:24 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2MV1-00087Z-F0 for pcn@ietf.org; Wed, 12 Dec 2007 02:59:23 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 12 Dec 2007 08:59:18 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Dec 2007 08:59:18 +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] Questions on centralised control nodes Date: Wed, 12 Dec 2007 08:59:18 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C1626@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1197403234.21366.47.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on centralised control nodes Thread-Index: Acg8MI3uzSxuashgRVKF2/4k8cqKTgAZAeAA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 12 Dec 2007 07:59:18.0570 (UTC) FILETIME=[E5A548A0:01C83C94] 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 Steven, I share this view too, yes to both questions and no more=20 detailed comments from me this time. Regards,=20 Rudiger |-----Original Message----- |From: Steven Blake [mailto:steven.blake@ericsson.com] |Sent: Tuesday, December 11, 2007 9:01 PM |To: pcn |Subject: [PCN] Questions on centralised control nodes | | |During last week's meeting there was some discussion regarding the role |of centralised control nodes in PCN (see the preliminary minutes): | |1. Does there need to be any discussion of centralized=20 |decision nodes in | the architecture draft? | |2. If yes to (1), is the current text in the architecture draft | sufficient? | |By the judgement of the chairs, the consensus of the room for each |question was 1 - Yes, 2 - Yes. | |We are opening these questions for discussion on the list. Please |review the architecture draft -02 and send your feedback to the list. | | |Regards, | |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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 12 03:12: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 1J2Mi9-0004QS-2s; Wed, 12 Dec 2007 03:12:57 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2Mi6-0004PP-Ty for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 03:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Mi6-0004PH-Fm for pcn@ietf.org; Wed, 12 Dec 2007 03:12:54 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Mi3-0008Vr-Nf for pcn@ietf.org; Wed, 12 Dec 2007 03:12:53 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 12 Dec 2007 09:12:50 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Dec 2007 09:12:49 +0100 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] A two-layer approach for PCN Date: Wed, 12 Dec 2007 09:12:49 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C1627@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <475F09D2.9030804@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] A two-layer approach for PCN Thread-Index: Acg8QcnN2VPzs/uhSRKtq33UDF8uAQAU5lZw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 12 Dec 2007 08:12:49.0966 (UTC) FILETIME=[C9467CE0:01C83C96] X-Spam-Score: -1.0 (-) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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 Hello Michael, your proposal is in principle allright with me. If felt to be=20 useful by others to, I don't object to making it part of a=20 suitable WG document. One concern and a second question for clarification: - does there need to be a little text covering a multi domain PML case? This case would require interoperable ACFTL, I=20 assume. Your text on MPLS: ' o E3Tunnel Given: edge-to-edge MPLS tunnels; Egress node measures CLE for tunnel and depending on=20 that value,...' If you measure CLE for a tunnel at the egress, you assume=20 presence of a RSVP TE signaled tunnel. I assume. If so, I'd=20 appreciate the text mentioning RSVP TE explicitely. Regards, Rudiger |-----Original Message----- |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |Sent: Tuesday, December 11, 2007 11:06 PM |To: pcn |Subject: [PCN] A two-layer approach for PCN | | |Hi all, | |during last week's meeting I had discussions with many people=20 |regarding=20 |a separation of packet marking vs. admission control and flow=20 |termination aspects. The intention was to make the structure=20 |of PCN more=20 |obvious and to facilitate its adaptation to various network=20 |architectures. The following text reflects the outcome of=20 |these discussions. | |Comments are welcome. | |Regards, | | Michael | |-- | |The pre-congestion notification (PCN) architecture consists of two=20 |different layers: the packet marking layer (PML) and the admission=20 |control and flow termination layer (ACFTL). |The packet marking layer (PML) describes how PCN-capable=20 |interior nodes=20 |meter and mark PCN packets. Within a single network only one packet=20 |marking layer (PML) MUST be deployed, i.e. PCN-capable interior nodes=20 |MUST implement the same metering and marking behavior for all=20 |links. The=20 |admission control and flow termination layer (ACFTL) describes how PCN=20 |edge nodes make use of the packet markings observed by the PCN egress=20 |node to decide whether new flows can be accepted or whether already=20 |admitted flows need to be terminated. The implementation of the=20 |admission control and flow termination layer (ACFTL) may take=20 |advantage=20 |of specific transport architectures and may be tailored for various=20 |signaling architectures with which it needs to interoperate.=20 |In contrast=20 |to the packet marking layer (PML), different instances=20 |admission control=20 |and flow termination layers (ACFTL) MAY be used in the same network as=20 |long as they interpret the semantics of the packet markings in=20 |the same=20 |way and don't lead to unfairness issues. | | | +---+---+---+---+ | | A | A | . | A | | | C | C | . | C | | | F | F | . | F | | | T | T | . | T | | | L | L | . | L | | | | | | | | | 0 | 1 | . | n | | +---+---+---+---+ | | PML | | +---------------+ | |Figure 1: Within a single network, only one packet marking layer (PML) | MUST be deployed, but several admission control and flow | termination layers (ACFTL) MAY coexist. | |In the following, the concepts of the packet marking layer (PML) and=20 |admission control and flow termination layer (ACFTL) are briefly=20 |illustrated. | |4 examples of mutually exclusive interior node behaviors for=20 |implementation of the PML: | |a) Ramp marking based on the admissible rate and excess-rate marking=20 |based on the supportable rate (CL proposal) |b) Threshold marking based on the admissible rate and excess-rate=20 |marking with marking frequency reduction based on the supportable rate=20 |(3sm proposal) |c) Threshold marking based on the admissible rate and excess-rate=20 |marking based on the supportable rate (behavioral intersection=20 |of CL and=20 |3sm proposal) |d) Excess rate marking based on the admissible rate (Single Marking=20 |proposal) | |Note that only one packet marking layer (PML) can be deployed within a=20 |single network. | | |3 examples for different edge node behaviors for implementation of the=20 |admission control and flow termination layer (ACFTL) based on=20 |the packet=20 |marking layer b) above: | | o E3Tunnel | Given: edge-to-edge MPLS tunnels; | Egress node measures CLE for tunnel and depending on that value, it=20 |sends an "admission-stop" or "admission-continue" message to the=20 |corresponding ingress node that then stops or continues admitting=20 |further flows. | Flows are terminated when one of its packets was ET-marked. | o End2PS | Given: end-to-end on-path signalling protocol; | PCN egress node is a RSVP capable node and returns PATHERR if first=20 |PATH msg was "admission-stop" marked; PCN ingress node accepts=20 |all flows=20 |whose RESV messages come through.=20 | Flows are terminated when one of its packets was ET-marked: the PCN=20 |egress node sends a RESVTEAR message to the PCN ingress. | o Centralized node | Given: centralized node (CN) in charge of admitting or=20 |terminating flows; | Upon a new flow arrival, the CN issues an admission request to PCN=20 |ingress node for a future data flow with an indicated=20 |source-destination=20 |tuple; | CN sends a probe packet to the PCN egress node which returns the=20 |probe to the CN; the CN rejects the flow if probe was marked=20 |and admits=20 |it if probe was unmarked. | Flows are terminated when one of its packets was ET-marked. The PCN=20 |egress node sends the marked packet to the CN which terminated the=20 |corresponding flow. | |These admission control and flow termination layers (ACFTL) MAY=20 |simultaneously be applied in the same network. Similar methods can be=20 |defined based on the other packet marking layers (PML) defined above. | |Within the current charter, only one packet marking layer (PML) should=20 |be standardized as well as only one admission control and flow=20 |termination layer (ACFTL), presumably for ingress-egress aggregates.=20 |However, it is desirable that the architecture is extensible towards=20 |other admission control and flow termination layers (ACFTL) to address=20 |the need of various network architectures (e.g., without explicit=20 |aggregates, with multipath routing, with centralized control=20 |nodes, ...)=20 |that need QoS support in the future. | |Note: this text does not contradict the current version of the=20 |architecture draft. Essentially, the packet marking behavior=20 |of interior=20 |nodes is put into a packet marking layer and the admission control and=20 |flow termination behavior of edge nodes is put into an=20 |admission control=20 |and flow termination layer. The two-layer approach just makes the idea=20 |more explicit that different edge node behaviors may be defined for a=20 |single interior node behavior and that several edge node behaviors may=20 |coexist in the same network if necessary. | |--=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 Wed Dec 12 03:43: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 1J2NBf-0004dm-5w; Wed, 12 Dec 2007 03:43:27 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2NBe-0004df-5d for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 03:43:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2NBd-0004dX-Kk for pcn@ietf.org; Wed, 12 Dec 2007 03:43:25 -0500 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 1J2NBc-0000Ub-F2 for pcn@ietf.org; Wed, 12 Dec 2007 03:43:25 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id F1E50C5FD; Wed, 12 Dec 2007 09:43:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E4180C6FF; Wed, 12 Dec 2007 09:43:23 +0100 (CET) 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 AD68CC5FD; Wed, 12 Dec 2007 09:43:22 +0100 (CET) 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 lBC8hMI12284; Wed, 12 Dec 2007 09:43:22 +0100 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 B03BB6F591; Wed, 12 Dec 2007 09:35:22 +0100 (CET) Message-ID: <475F9F9F.7000201@informatik.uni-wuerzburg.de> Date: Wed, 12 Dec 2007 09:45:19 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] A two-layer approach for PCN References: <1B6169C658325341A3B8066E23919E1C4C1627@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C1627@S4DE8PSAANK.mitte.t-com.de> 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: 0bb031f3a6fb29f760794ac9bf1997ae 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 Ruediger, Geib, Ruediger wrote: > Hello Michael, > > your proposal is in principle allright with me. If felt to be > useful by others to, I don't object to making it part of a > suitable WG document. > > One concern and a second question for clarification: > > - does there need to be a little text covering a multi domain > PML case? This case would require interoperable ACFTL, I > assume. > Well, so far, we haven't really considered interdomain-PCN and it is not yet clear how and whether it works and the two-layer description is orthogonal to the aspect of interdomain-PCN. Nevertheless, interdomain-PCN would require a single packet marking layer (PML) and admission control and flow termination layers (ACFTL) at the end (?) nodes that make consistent use of the packet markings. That is probably what you mean and I share your view. However, I don't know how these ACFTL look like. > Your text on MPLS: > ' o E3Tunnel > Given: edge-to-edge MPLS tunnels; > Egress node measures CLE for tunnel and depending on > that value,...' > > If you measure CLE for a tunnel at the egress, you assume > presence of a RSVP TE signaled tunnel. I assume. If so, I'd > appreciate the text mentioning RSVP TE explicitely. > This does not hold only for RSVP TE tunnels, other tunnels, e.g. manually configured tunnels are also appropriate as long as they are carried over a single (explicit) path. But E3Tunnel is just an example anyway. Regards, Michael > Regards, > > Rudiger > > > |-----Original Message----- > |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > |Sent: Tuesday, December 11, 2007 11:06 PM > |To: pcn > |Subject: [PCN] A two-layer approach for PCN > | > | > |Hi all, > | > |during last week's meeting I had discussions with many people > |regarding > |a separation of packet marking vs. admission control and flow > |termination aspects. The intention was to make the structure > |of PCN more > |obvious and to facilitate its adaptation to various network > |architectures. The following text reflects the outcome of > |these discussions. > | > |Comments are welcome. > | > |Regards, > | > | Michael > | > |-- > | > |The pre-congestion notification (PCN) architecture consists of two > |different layers: the packet marking layer (PML) and the admission > |control and flow termination layer (ACFTL). > |The packet marking layer (PML) describes how PCN-capable > |interior nodes > |meter and mark PCN packets. Within a single network only one packet > |marking layer (PML) MUST be deployed, i.e. PCN-capable interior nodes > |MUST implement the same metering and marking behavior for all > |links. The > |admission control and flow termination layer (ACFTL) describes how PCN > |edge nodes make use of the packet markings observed by the PCN egress > |node to decide whether new flows can be accepted or whether already > |admitted flows need to be terminated. The implementation of the > |admission control and flow termination layer (ACFTL) may take > |advantage > |of specific transport architectures and may be tailored for various > |signaling architectures with which it needs to interoperate. > |In contrast > |to the packet marking layer (PML), different instances > |admission control > |and flow termination layers (ACFTL) MAY be used in the same network as > |long as they interpret the semantics of the packet markings in > |the same > |way and don't lead to unfairness issues. > | > | > | +---+---+---+---+ > | | A | A | . | A | > | | C | C | . | C | > | | F | F | . | F | > | | T | T | . | T | > | | L | L | . | L | > | | | | | | > | | 0 | 1 | . | n | > | +---+---+---+---+ > | | PML | > | +---------------+ > | > |Figure 1: Within a single network, only one packet marking layer (PML) > | MUST be deployed, but several admission control and flow > | termination layers (ACFTL) MAY coexist. > | > |In the following, the concepts of the packet marking layer (PML) and > |admission control and flow termination layer (ACFTL) are briefly > |illustrated. > | > |4 examples of mutually exclusive interior node behaviors for > |implementation of the PML: > | > |a) Ramp marking based on the admissible rate and excess-rate marking > |based on the supportable rate (CL proposal) > |b) Threshold marking based on the admissible rate and excess-rate > |marking with marking frequency reduction based on the supportable rate > |(3sm proposal) > |c) Threshold marking based on the admissible rate and excess-rate > |marking based on the supportable rate (behavioral intersection > |of CL and > |3sm proposal) > |d) Excess rate marking based on the admissible rate (Single Marking > |proposal) > | > |Note that only one packet marking layer (PML) can be deployed within a > |single network. > | > | > |3 examples for different edge node behaviors for implementation of the > |admission control and flow termination layer (ACFTL) based on > |the packet > |marking layer b) above: > | > | o E3Tunnel > | Given: edge-to-edge MPLS tunnels; > | Egress node measures CLE for tunnel and depending on that value, it > |sends an "admission-stop" or "admission-continue" message to the > |corresponding ingress node that then stops or continues admitting > |further flows. > | Flows are terminated when one of its packets was ET-marked. > | o End2PS > | Given: end-to-end on-path signalling protocol; > | PCN egress node is a RSVP capable node and returns PATHERR if first > |PATH msg was "admission-stop" marked; PCN ingress node accepts > |all flows > |whose RESV messages come through. > | Flows are terminated when one of its packets was ET-marked: the PCN > |egress node sends a RESVTEAR message to the PCN ingress. > | o Centralized node > | Given: centralized node (CN) in charge of admitting or > |terminating flows; > | Upon a new flow arrival, the CN issues an admission request to PCN > |ingress node for a future data flow with an indicated > |source-destination > |tuple; > | CN sends a probe packet to the PCN egress node which returns the > |probe to the CN; the CN rejects the flow if probe was marked > |and admits > |it if probe was unmarked. > | Flows are terminated when one of its packets was ET-marked. The PCN > |egress node sends the marked packet to the CN which terminated the > |corresponding flow. > | > |These admission control and flow termination layers (ACFTL) MAY > |simultaneously be applied in the same network. Similar methods can be > |defined based on the other packet marking layers (PML) defined above. > | > |Within the current charter, only one packet marking layer (PML) should > |be standardized as well as only one admission control and flow > |termination layer (ACFTL), presumably for ingress-egress aggregates. > |However, it is desirable that the architecture is extensible towards > |other admission control and flow termination layers (ACFTL) to address > |the need of various network architectures (e.g., without explicit > |aggregates, with multipath routing, with centralized control > |nodes, ...) > |that need QoS support in the future. > | > |Note: this text does not contradict the current version of the > |architecture draft. Essentially, the packet marking behavior > |of interior > |nodes is put into a packet marking layer and the admission control and > |flow termination behavior of edge nodes is put into an > |admission control > |and flow termination layer. The two-layer approach just makes the idea > |more explicit that different edge node behaviors may be defined for a > |single interior node behavior and that several edge node behaviors may > |coexist in the same network if necessary. > | > |-- > |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 > | > -- 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 Dec 12 04:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ny3-00084g-OV; Wed, 12 Dec 2007 04:33:27 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2Ny2-0007yu-E9 for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 04:33:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ny1-0007su-Rp for pcn@ietf.org; Wed, 12 Dec 2007 04:33:25 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Nxz-0002LM-Ji for pcn@ietf.org; Wed, 12 Dec 2007 04:33:25 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 12 Dec 2007 10:33:19 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Dec 2007 10:33: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] A two-layer approach for PCN Date: Wed, 12 Dec 2007 10:33:16 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C1628@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <475F9F9F.7000201@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] A two-layer approach for PCN Thread-Index: Acg8mxLKNuV9p9lES16ZuvIJuRy/tgABbvRw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 12 Dec 2007 09:33:16.0883 (UTC) FILETIME=[06579230:01C83CA2] X-Spam-Score: -1.0 (-) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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 Michael, |> Your text on MPLS: |> ' o E3Tunnel |> Given: edge-to-edge MPLS tunnels; |> Egress node measures CLE for tunnel and depending on=20 |> that value,...' |> |> If you measure CLE for a tunnel at the egress, you assume=20 |> presence of a RSVP TE signaled tunnel. I assume. If so, I'd=20 |> appreciate the text mentioning RSVP TE explicitely. |> =20 | |This does not hold only for RSVP TE tunnels, other tunnels, e.g.=20 |manually configured tunnels are also appropriate as long as they are=20 |carried over a single (explicit) path. But E3Tunnel is just an example=20 |anyway. My point is the distinction from Label Switched Paths established=20 by LDP. LDP sets up multipoint to point tunnels. Your text describes=20 a solution valid for point to point tunnels, doesn't it? If yes, may=20 be a sentence mentioning that this scenario holds for point to point=20 tunnels may be helpful. Regards, Rudiger |> |-----Original Message----- |> |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |> |Sent: Tuesday, December 11, 2007 11:06 PM |> |To: pcn |> |Subject: [PCN] A two-layer approach for PCN |> | |> | |> |Hi all, |> | |> |during last week's meeting I had discussions with many people=20 |> |regarding=20 |> |a separation of packet marking vs. admission control and flow=20 |> |termination aspects. The intention was to make the structure=20 |> |of PCN more=20 |> |obvious and to facilitate its adaptation to various network=20 |> |architectures. The following text reflects the outcome of=20 |> |these discussions. |> | |> |Comments are welcome. |> | |> |Regards, |> | |> | Michael |> | |> |-- |> | |> |The pre-congestion notification (PCN) architecture consists of two=20 |> |different layers: the packet marking layer (PML) and the admission=20 |> |control and flow termination layer (ACFTL). |> |The packet marking layer (PML) describes how PCN-capable=20 |> |interior nodes=20 |> |meter and mark PCN packets. Within a single network only one packet=20 |> |marking layer (PML) MUST be deployed, i.e. PCN-capable=20 |interior nodes=20 |> |MUST implement the same metering and marking behavior for all=20 |> |links. The=20 |> |admission control and flow termination layer (ACFTL)=20 |describes how PCN=20 |> |edge nodes make use of the packet markings observed by the=20 |PCN egress=20 |> |node to decide whether new flows can be accepted or whether already=20 |> |admitted flows need to be terminated. The implementation of the=20 |> |admission control and flow termination layer (ACFTL) may take=20 |> |advantage=20 |> |of specific transport architectures and may be tailored for various=20 |> |signaling architectures with which it needs to interoperate.=20 |> |In contrast=20 |> |to the packet marking layer (PML), different instances=20 |> |admission control=20 |> |and flow termination layers (ACFTL) MAY be used in the same=20 |network as=20 |> |long as they interpret the semantics of the packet markings in=20 |> |the same=20 |> |way and don't lead to unfairness issues. |> | |> | |> | +---+---+---+---+ |> | | A | A | . | A | |> | | C | C | . | C | |> | | F | F | . | F | |> | | T | T | . | T | |> | | L | L | . | L | |> | | | | | | |> | | 0 | 1 | . | n | |> | +---+---+---+---+ |> | | PML | |> | +---------------+ |> | |> |Figure 1: Within a single network, only one packet marking=20 |layer (PML) |> | MUST be deployed, but several admission control and flow |> | termination layers (ACFTL) MAY coexist. |> | |> |In the following, the concepts of the packet marking layer=20 |(PML) and=20 |> |admission control and flow termination layer (ACFTL) are briefly=20 |> |illustrated. |> | |> |4 examples of mutually exclusive interior node behaviors for=20 |> |implementation of the PML: |> | |> |a) Ramp marking based on the admissible rate and=20 |excess-rate marking=20 |> |based on the supportable rate (CL proposal) |> |b) Threshold marking based on the admissible rate and excess-rate=20 |> |marking with marking frequency reduction based on the=20 |supportable rate=20 |> |(3sm proposal) |> |c) Threshold marking based on the admissible rate and excess-rate=20 |> |marking based on the supportable rate (behavioral intersection=20 |> |of CL and=20 |> |3sm proposal) |> |d) Excess rate marking based on the admissible rate (Single Marking=20 |> |proposal) |> | |> |Note that only one packet marking layer (PML) can be=20 |deployed within a=20 |> |single network. |> | |> | |> |3 examples for different edge node behaviors for=20 |implementation of the=20 |> |admission control and flow termination layer (ACFTL) based on=20 |> |the packet=20 |> |marking layer b) above: |> | |> | o E3Tunnel |> | Given: edge-to-edge MPLS tunnels; |> | Egress node measures CLE for tunnel and depending on=20 |that value, it=20 |> |sends an "admission-stop" or "admission-continue" message to the=20 |> |corresponding ingress node that then stops or continues admitting=20 |> |further flows. |> | Flows are terminated when one of its packets was ET-marked. |> | o End2PS |> | Given: end-to-end on-path signalling protocol; |> | PCN egress node is a RSVP capable node and returns=20 |PATHERR if first=20 |> |PATH msg was "admission-stop" marked; PCN ingress node accepts=20 |> |all flows=20 |> |whose RESV messages come through.=20 |> | Flows are terminated when one of its packets was=20 |ET-marked: the PCN=20 |> |egress node sends a RESVTEAR message to the PCN ingress. |> | o Centralized node |> | Given: centralized node (CN) in charge of admitting or=20 |> |terminating flows; |> | Upon a new flow arrival, the CN issues an admission=20 |request to PCN=20 |> |ingress node for a future data flow with an indicated=20 |> |source-destination=20 |> |tuple; |> | CN sends a probe packet to the PCN egress node which returns the=20 |> |probe to the CN; the CN rejects the flow if probe was marked=20 |> |and admits=20 |> |it if probe was unmarked. |> | Flows are terminated when one of its packets was=20 |ET-marked. The PCN=20 |> |egress node sends the marked packet to the CN which terminated the=20 |> |corresponding flow. |> | |> |These admission control and flow termination layers (ACFTL) MAY=20 |> |simultaneously be applied in the same network. Similar=20 |methods can be=20 |> |defined based on the other packet marking layers (PML)=20 |defined above. |> | |> |Within the current charter, only one packet marking layer=20 |(PML) should=20 |> |be standardized as well as only one admission control and flow=20 |> |termination layer (ACFTL), presumably for ingress-egress=20 |aggregates.=20 |> |However, it is desirable that the architecture is=20 |extensible towards=20 |> |other admission control and flow termination layers (ACFTL)=20 |to address=20 |> |the need of various network architectures (e.g., without explicit=20 |> |aggregates, with multipath routing, with centralized control=20 |> |nodes, ...)=20 |> |that need QoS support in the future. |> | |> |Note: this text does not contradict the current version of the=20 |> |architecture draft. Essentially, the packet marking behavior=20 |> |of interior=20 |> |nodes is put into a packet marking layer and the admission=20 |control and=20 |> |flow termination behavior of edge nodes is put into an=20 |> |admission control=20 |> |and flow termination layer. The two-layer approach just=20 |makes the idea=20 |> |more explicit that different edge node behaviors may be=20 |defined for a=20 |> |single interior node behavior and that several edge node=20 |behaviors may=20 |> |coexist in the same network if necessary. |> | |> |--=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 |> | |> =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 Dec 12 04:59: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 1J2ONL-0003V7-Jo; Wed, 12 Dec 2007 04:59:35 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2ONJ-0003Ul-CJ for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 04:59:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ONI-0003Tf-RO for pcn@ietf.org; Wed, 12 Dec 2007 04:59:32 -0500 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 1J2ONH-00032d-HF for pcn@ietf.org; Wed, 12 Dec 2007 04:59:32 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DDB84B269; Wed, 12 Dec 2007 10:59:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id D05A21000E; Wed, 12 Dec 2007 10:59:30 +0100 (CET) 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 94D4C10011; Wed, 12 Dec 2007 10:59:29 +0100 (CET) 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 lBC9xTI13250; Wed, 12 Dec 2007 10:59:29 +0100 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 7E1D76F591; Wed, 12 Dec 2007 10:51:29 +0100 (CET) Message-ID: <475FB176.7040009@informatik.uni-wuerzburg.de> Date: Wed, 12 Dec 2007 11:01:26 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] A two-layer approach for PCN References: <1B6169C658325341A3B8066E23919E1C4C1628@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C1628@S4DE8PSAANK.mitte.t-com.de> 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: 8068004c042dabd7f1301bcc80e039df 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 Ruediger, please see inline! Geib, Ruediger wrote: > Hi Michael, > > |> Your text on MPLS: > |> ' o E3Tunnel > |> Given: edge-to-edge MPLS tunnels; > |> Egress node measures CLE for tunnel and depending on > |> that value,...' > |> > |> If you measure CLE for a tunnel at the egress, you assume > |> presence of a RSVP TE signaled tunnel. I assume. If so, I'd > |> appreciate the text mentioning RSVP TE explicitely. > |> > | > |This does not hold only for RSVP TE tunnels, other tunnels, e.g. > |manually configured tunnels are also appropriate as long as they are > |carried over a single (explicit) path. But E3Tunnel is just an example > |anyway. > > My point is the distinction from Label Switched Paths established > by LDP. LDP sets up multipoint to point tunnels. Your text describes > a solution valid for point to point tunnels, doesn't it? If yes, may > be a sentence mentioning that this scenario holds for point to point > tunnels may be helpful. > Ok, now I see your point. You are right: multipoint-to-point tunnels set up by LDP do not match the E3Tunnel example since these tunnel structures are not (single)edge-to-(single)edge. In general, with multipoint-to-point tunnels it becomes harder than with point-to-point tunnels to map the packets at the PCN egress node to the corresponding PCN ingress node, I think. Regards, Michael > Regards, > > Rudiger > > |> |-----Original Message----- > |> |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > |> |Sent: Tuesday, December 11, 2007 11:06 PM > |> |To: pcn > |> |Subject: [PCN] A two-layer approach for PCN > |> | > |> | > |> |Hi all, > |> | > |> |during last week's meeting I had discussions with many people > |> |regarding > |> |a separation of packet marking vs. admission control and flow > |> |termination aspects. The intention was to make the structure > |> |of PCN more > |> |obvious and to facilitate its adaptation to various network > |> |architectures. The following text reflects the outcome of > |> |these discussions. > |> | > |> |Comments are welcome. > |> | > |> |Regards, > |> | > |> | Michael > |> | > |> |-- > |> | > |> |The pre-congestion notification (PCN) architecture consists of two > |> |different layers: the packet marking layer (PML) and the admission > |> |control and flow termination layer (ACFTL). > |> |The packet marking layer (PML) describes how PCN-capable > |> |interior nodes > |> |meter and mark PCN packets. Within a single network only one packet > |> |marking layer (PML) MUST be deployed, i.e. PCN-capable > |interior nodes > |> |MUST implement the same metering and marking behavior for all > |> |links. The > |> |admission control and flow termination layer (ACFTL) > |describes how PCN > |> |edge nodes make use of the packet markings observed by the > |PCN egress > |> |node to decide whether new flows can be accepted or whether already > |> |admitted flows need to be terminated. The implementation of the > |> |admission control and flow termination layer (ACFTL) may take > |> |advantage > |> |of specific transport architectures and may be tailored for various > |> |signaling architectures with which it needs to interoperate. > |> |In contrast > |> |to the packet marking layer (PML), different instances > |> |admission control > |> |and flow termination layers (ACFTL) MAY be used in the same > |network as > |> |long as they interpret the semantics of the packet markings in > |> |the same > |> |way and don't lead to unfairness issues. > |> | > |> | > |> | +---+---+---+---+ > |> | | A | A | . | A | > |> | | C | C | . | C | > |> | | F | F | . | F | > |> | | T | T | . | T | > |> | | L | L | . | L | > |> | | | | | | > |> | | 0 | 1 | . | n | > |> | +---+---+---+---+ > |> | | PML | > |> | +---------------+ > |> | > |> |Figure 1: Within a single network, only one packet marking > |layer (PML) > |> | MUST be deployed, but several admission control and flow > |> | termination layers (ACFTL) MAY coexist. > |> | > |> |In the following, the concepts of the packet marking layer > |(PML) and > |> |admission control and flow termination layer (ACFTL) are briefly > |> |illustrated. > |> | > |> |4 examples of mutually exclusive interior node behaviors for > |> |implementation of the PML: > |> | > |> |a) Ramp marking based on the admissible rate and > |excess-rate marking > |> |based on the supportable rate (CL proposal) > |> |b) Threshold marking based on the admissible rate and excess-rate > |> |marking with marking frequency reduction based on the > |supportable rate > |> |(3sm proposal) > |> |c) Threshold marking based on the admissible rate and excess-rate > |> |marking based on the supportable rate (behavioral intersection > |> |of CL and > |> |3sm proposal) > |> |d) Excess rate marking based on the admissible rate (Single Marking > |> |proposal) > |> | > |> |Note that only one packet marking layer (PML) can be > |deployed within a > |> |single network. > |> | > |> | > |> |3 examples for different edge node behaviors for > |implementation of the > |> |admission control and flow termination layer (ACFTL) based on > |> |the packet > |> |marking layer b) above: > |> | > |> | o E3Tunnel > |> | Given: edge-to-edge MPLS tunnels; > |> | Egress node measures CLE for tunnel and depending on > |that value, it > |> |sends an "admission-stop" or "admission-continue" message to the > |> |corresponding ingress node that then stops or continues admitting > |> |further flows. > |> | Flows are terminated when one of its packets was ET-marked. > |> | o End2PS > |> | Given: end-to-end on-path signalling protocol; > |> | PCN egress node is a RSVP capable node and returns > |PATHERR if first > |> |PATH msg was "admission-stop" marked; PCN ingress node accepts > |> |all flows > |> |whose RESV messages come through. > |> | Flows are terminated when one of its packets was > |ET-marked: the PCN > |> |egress node sends a RESVTEAR message to the PCN ingress. > |> | o Centralized node > |> | Given: centralized node (CN) in charge of admitting or > |> |terminating flows; > |> | Upon a new flow arrival, the CN issues an admission > |request to PCN > |> |ingress node for a future data flow with an indicated > |> |source-destination > |> |tuple; > |> | CN sends a probe packet to the PCN egress node which returns the > |> |probe to the CN; the CN rejects the flow if probe was marked > |> |and admits > |> |it if probe was unmarked. > |> | Flows are terminated when one of its packets was > |ET-marked. The PCN > |> |egress node sends the marked packet to the CN which terminated the > |> |corresponding flow. > |> | > |> |These admission control and flow termination layers (ACFTL) MAY > |> |simultaneously be applied in the same network. Similar > |methods can be > |> |defined based on the other packet marking layers (PML) > |defined above. > |> | > |> |Within the current charter, only one packet marking layer > |(PML) should > |> |be standardized as well as only one admission control and flow > |> |termination layer (ACFTL), presumably for ingress-egress > |aggregates. > |> |However, it is desirable that the architecture is > |extensible towards > |> |other admission control and flow termination layers (ACFTL) > |to address > |> |the need of various network architectures (e.g., without explicit > |> |aggregates, with multipath routing, with centralized control > |> |nodes, ...) > |> |that need QoS support in the future. > |> | > |> |Note: this text does not contradict the current version of the > |> |architecture draft. Essentially, the packet marking behavior > |> |of interior > |> |nodes is put into a packet marking layer and the admission > |control and > |> |flow termination behavior of edge nodes is put into an > |> |admission control > |> |and flow termination layer. The two-layer approach just > |makes the idea > |> |more explicit that different edge node behaviors may be > |defined for a > |> |single interior node behavior and that several edge node > |behaviors may > |> |coexist in the same network if necessary. > |> | > |> |-- > |> |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 > |> | > |> > | > |-- > |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 > | > | > -- 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 Dec 12 05:22: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 1J2Oj5-0001zV-GJ; Wed, 12 Dec 2007 05:22:03 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2Oj3-0001yl-6r for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 05:22:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Oj2-0001ya-NX for pcn@ietf.org; Wed, 12 Dec 2007 05:22:00 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Oj1-0003RI-0t for pcn@ietf.org; Wed, 12 Dec 2007 05:22:00 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lBCALhft014802; Wed, 12 Dec 2007 11:21:57 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , "'pcn'" References: <1197397615.21366.38.camel@neutrino> Subject: RE: [PCN] Questions on probing Date: Wed, 12 Dec 2007 11:21:38 +0100 Message-ID: <000201c83ca8$cca448b0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg8I3VTGuNG3yt8Qaum9ZZ2LdiYPgAg/qUg In-Reply-To: <1197397615.21366.38.camel@neutrino> X-Spam-Score: 0.087 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 12 Dec 2007 11:21:57 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Steven, Hi all Regarding the questions sent you can fing my answers below. * Regarding question (1), Yes, I think it is needed to have a discussion of probing in the architecture draft. * Regarding queestion (2), Yes and No. The current text is correct up to a certain point. Below I resend the comment that I have sent some time ago on the PCN list: In Section 7.3, page 29, you provide the below conclusion on the viewpoint that admission control is always done by probing: "The first point breaks Assumption 3 (aggregation) and hence means that this viewpoint is out of scope of initial Charter of the PCN WG." I do not agree with this conclusion, since I do not agree with the argumentation that the first point breaks Assumption 3 more than the situation that no probing is used during admission control. Therefore, please remove the sentence: "The first point breaks Assumption 3 (aggregation) and hence means that this viewpoint is out of scope of initial Charter of the PCN WG." * Regarding question (3), No, I do not think that working group need to do protocol work on probing prior to last call for the architecture draft? Best regards, Georgios > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: dinsdag 11 december 2007 19:27 > To: pcn > Subject: [PCN] Questions on probing > > During last week's meeting there was some discussion > regarding the role of probing in PCN (see the preliminary minutes): > > 1. Does there need to be any discussion of probing in the architecture > draft? > > 2. If yes to (1), is the current text in the architecture draft > essentially correct and sufficient? > > 3. Does the working group need to do protocol work on probing prior to > last call for the architecture draft? > > By the judgement of the chairs, the consensus of the room for > each question was 1 - Yes, 2 - Yes, 3 - No (and these weren't > close calls). > > We are opening these questions for discussion on the list. > Please review the architecture draft -02 (especially Sec. 7) > and send your feedback to the list. > > > Regards, > > 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 From pcn-bounces@ietf.org Wed Dec 12 05:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2OtK-00068l-MZ; Wed, 12 Dec 2007 05:32:38 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2OtK-00068g-6m for pcn-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 05:32:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2OtJ-00068Y-T8 for pcn@ietf.org; Wed, 12 Dec 2007 05:32:37 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2OtJ-0003ep-DO for pcn@ietf.org; Wed, 12 Dec 2007 05:32:37 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lBCAWUSt015891; Wed, 12 Dec 2007 11:32:36 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , "'pcn'" References: <1197403234.21366.47.camel@neutrino> Subject: RE: [PCN] Questions on centralised control nodes Date: Wed, 12 Dec 2007 11:32:25 +0100 Message-ID: <000301c83caa$4cbf2000$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg8MJXWjxUsnRxkQaW0CyuPvd/FmAAeXfTw In-Reply-To: <1197403234.21366.47.camel@neutrino> X-Spam-Score: 0.087 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 12 Dec 2007 11:32:36 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Steven, Hi all My answer to the below two questions is: * Question 1, Yes * Question 2, yes Best regards, Georgios > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: dinsdag 11 december 2007 21:01 > To: pcn > Subject: [PCN] Questions on centralised control nodes > > During last week's meeting there was some discussion > regarding the role of centralised control nodes in PCN (see > the preliminary minutes): > > 1. Does there need to be any discussion of centralized > decision nodes in > the architecture draft? > > 2. If yes to (1), is the current text in the architecture draft > sufficient? > > By the judgement of the chairs, the consensus of the room for > each question was 1 - Yes, 2 - Yes. > > We are opening these questions for discussion on the list. > Please review the architecture draft -02 and send your > feedback to the list. > > > Regards, > > 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 From pcn-bounces@ietf.org Thu Dec 13 07:34: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 1J2nGT-0000Uh-BZ; Thu, 13 Dec 2007 07:34:09 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2nGR-0000UK-Q1 for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 07:34:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nGR-0000UB-CN for pcn@ietf.org; Thu, 13 Dec 2007 07:34:07 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2nGQ-000225-V6 for pcn@ietf.org; Thu, 13 Dec 2007 07:34:07 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 12:34:19 +0000 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] Questions on probing Date: Thu, 13 Dec 2007 12:34:18 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3440D@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000201c83ca8$cca448b0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing thread-index: Acg8I3VTGuNG3yt8Qaum9ZZ2LdiYPgAg/qUgADcQwSA= From: To: , , X-OriginalArrivalTime: 13 Dec 2007 12:34:19.0954 (UTC) FILETIME=[7BA66920:01C83D84] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Georgios To pick up on our of your comments, which concerns the archit draft >=20 > "The first point breaks Assumption 3 (aggregation) and hence means that > this > viewpoint is out of scope of initial Charter of the PCN WG." >=20 > I do not agree with this conclusion, since I do not agree with the > argumentation that the first point breaks Assumption 3 more than the > situation that no probing is used during admission control. > Therefore, please remove the sentence: > "The first point breaks Assumption 3 (aggregation) and hence means that > this > viewpoint is out of scope of initial Charter of the PCN WG." >=20 I don't understand your comment, and wonder if it's just that the section is not very clear about the context of the draft at this point.=20 the third viewpoint on 'why do probing' is simply 'admission control is always done by probing'. It assumes the following: o Simply admitting the new flow has a significant risk of leading to overload, because the PCN-domain reaches out towards the end terminals where link capacity is low. o Every admission control decision involves probing, using the signalling set-up message as the probe packet (eg RSVP PATH). o The PCN-marking behaviour is such that every packet is PCN-marked if the flow should be blocked, hence only a single probing packet is needed. I think the first of these bullets breaks Assumption 3 (aggregation) and hence means that this viewpoint is out of scope of the initial Charter of the PCN WG. phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 13 07:35: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 1J2nHy-00018T-1g; Thu, 13 Dec 2007 07:35:42 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2nHx-00018O-Fx for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 07:35:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nHx-00018G-3Z for pcn@ietf.org; Thu, 13 Dec 2007 07:35:41 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2nHw-00023m-7W for pcn@ietf.org; Thu, 13 Dec 2007 07:35:41 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 12:35:53 +0000 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, 13 Dec 2007 12:35:52 +0000 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 1197549334975; Thu, 13 Dec 2007 12:35:34 +0000 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 lBDCZ2AG013166; Thu, 13 Dec 2007 12:35:18 GMT Message-Id: <5.2.1.1.2.20071213120528.04020da0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 13 Dec 2007 12:35:23 +0000 To: "Ingemar Johansson S" From: Bob Briscoe Subject: RE: [PCN] Re: ECN support in a PCN domain In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0506579B9B@esealmw109.eemea. ericsson.se> References: <002801c834e4$b1237d20$0100c80a@comm.ad.roke.co.uk> <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de> <4751B463.1050107@ericsson.com> <002801c834e4$b1237d20$0100c80a@comm.ad.roke.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: 13 Dec 2007 12:35:52.0580 (UTC) FILETIME=[B2DC0440:01C83D84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 Ingemar, I've now read the 3GPP refs below. I just wanted to list the translations of the abbreviations I had to look up, both as a service to anyone else trying to read the 3GPP docs who doesn't come from a 3GPP background :) and to ask you to check I'm got them correct... GBR guaranteed bit rate MBR maximum bit rate AMBR aggregate maximum bit rate OBR offered bit rate AMR adaptive multirate PSS packet-switched streaming service EPS evolved packet service (= system architecture evolution (SAE)) EPC evolved packet core MTSI multimedia telephony service for IMS (IP Multimedia Subsystem) eNB enhanced node B (base station) FFS for further/future study --- Sorry the list isn't exhaustive - there were more that I haven't listed 'cos I knew them already. Bob At 19:52 03/12/2007, Ingemar Johansson S wrote: >Hi > >Because of the discussion of the possible use of ECN for other things >than TCP, below a collection of refrences with potential use cases that >perhaps highlights the benefits of being able to keep ECN transparent >end2end even through a PCN domain without the need to downgrade to best >effort or something similar. > >Regards >Ingemar >========================= >Thesis reports: >Fredrik Hultin >"Congestion notification and rate-adaptation for real-time services in >All-IP radio networks" >http://epubl.ltu.se/1402-1617/2007/244/LTU-EX-07244-SE.pdf >Sarker, A.N.M. Zaheduzzaman >"A study on adaptive real time video over LTE " >http://epubl.ltu.se/1653-0187/2007/064/LTU-PB-EX-07064-SE.pdf >The two thesis reports was written in parallel where the first dealt >with the network and the second dealt with the application. > >There is also ongoing some work regarding this in 3GPP, below a >collection of documents that may be of interest. >S4-070563:Real-time adaptive communication services in LTE > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_45/Docs/S4-070563.zip >Mentions only the word "congestion warning" but refers to... >S2-073328:Rate adaptation with "MBR>GBR bearers" > >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_59_Helsinki/Docs/S2-073328 >.zip >Describes how ECN can be used for MBR<->GBR bearers > >Additionally: >S2-075184: >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518 >4.zip >S2-075185: >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518 >5.zip >Latest documents in 3GPP RAN2 that deals with the use of ECN >========================= > > > > -----Original Message----- > > From: Robert Hancock [mailto:robert.hancock@roke.co.uk] > > Sent: den 2 december 2007 05:10 > > To: Magnus Westerlund; 'Lars Eggert' > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Re: ECN support in a PCN domain > > > > hi, > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Lars Eggert skrev: > > > > (I saw the idea in Robert's recent email of "downgrading" > > > ECN-enabled > > > > flows into the best-effort class of PCN. I need to think > > more about > > > > this, but on first glance this looks like a pretty elegant > > > resolution. > > > > A flow that is ECN-enabled has basically announced to the > > > network that > > > > it will react to loss in some way, i.e., probably has > > some form of > > > > congestion control. But I need to think about this more.) > > > > > > > > > > Well, that assumes that you never want to run ECN on something that > > > uses PCN. I think that assumption is wrong. A use case for PCN is > > > within a cellular core network. Where you use PCN to ensure > > that your > > > voice traffic get the best possible QoS through the core > > network. Even > > > in such a situation you have wireless links that you can't > > provide any > > > guarantees for and congestion may arise. To my knowledge ECN isn't > > > used yet but could be. > > > > > > I wished we where on clearer ground when it comes to real-time ECN > > > usage. > > > > To be clear, I am quite happy with there being use cases for > > ECN being used with traffic that also goes through an > > admission control process for some sort of capacity > > reservation (indeed, I can think of some additional ones). I > > think the only reason ECN concepts are so closely associated > > with TCP is the relative lack of other sorts of traffic in > > the wild until quite recently. > > > > So, the point is not to claim that ECN and PCN should never > > be used together. Rather, it's to suggest that if it's the > > case that even *if* it's impossible to find a PCN solution which both > > - is simple enough to get initial deployment, and > > - avoids trampling the ECN bits > > then there is still a case for a simple PCN solution which > > only helps non-ECN traffic if it also does no harm to ECN traffic. > > PCN will be better than nothing for some traffic, and not > > worse than the status quo for everything else. A PCN solution > > which is better than nothing for all traffic could be a > > subsequent evolution. > > > > (Really I guess this is all a discussion about whether there > > are simple, feasible solutions which 'cleanly integrate with > > ECN' in the language of the charter.) > > > > robert h. > > > > > > > > > > _______________________________________________ > > 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 ____________________________________________________________________________ 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 Dec 13 07:55: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 1J2nbZ-0003yL-3U; Thu, 13 Dec 2007 07:55:57 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2nbY-0003y1-7Z for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 07:55:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nbX-0003xt-QU for pcn@ietf.org; Thu, 13 Dec 2007 07:55:55 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2nbV-0000qk-Si for pcn@ietf.org; Thu, 13 Dec 2007 07:55:55 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 12:56:07 +0000 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] Questions on probing Date: Thu, 13 Dec 2007 12:56:06 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34411@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C1625@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing thread-index: Acg8I3dt8tgYDbcSR660DmqjIYiYYQAb4FZwAD0Y4uA= From: To: , X-OriginalArrivalTime: 13 Dec 2007 12:56:07.0715 (UTC) FILETIME=[8722E730:01C83D87] X-Spam-Score: -1.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 Rudiger Thanks, will work through the detailed comments when I do the next rev, and also think about your suggestion of moving some of the text to an annex. phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 12 December 2007 07:57 > To: steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Questions on probing >=20 > Steve, >=20 > generally I share the view of the room. I think the text in the > architecture-02 is still focused to much on an expectation that probing > is a regular requirement. I've commented on that earlier and attach my > comments again below. >=20 > If agreement is to progress the architecture without further discussion > on probing, I can accept that. >=20 > Regards, >=20 > Rudiger >=20 > Comments in line. >=20 > |During last week's meeting there was some discussion regarding the role > |of probing in PCN (see the preliminary minutes): > | > |1. Does there need to be any discussion of probing in the architecture > | draft? >=20 > Yes. >=20 > |2. If yes to (1), is the current text in the architecture draft > | essentially correct and sufficient? >=20 > My general take on the probing disussion: Leave just section '7.1 > Introduction' in the architecture and refer to another document > for a detailed discussion. Alternatively, move 7.2 and 7.3 to > the annex of the architecture doc. >=20 > |3. Does the working group need to do protocol work on probing prior to > | last call for the architecture draft? >=20 > No. >=20 > Detailed comments: >=20 > 7.1. Introduction (to probing) >=20 > 2nd paragraph, last sentence >=20 > "This risk could be lessened by configuring on each link > sufficient 'safety margin' above the PCN-lower-rate." >=20 > Please add: >=20 > "Further, the decision could be based on whether any of > the boundary nodes involved in admission of the new flow > on the unused aggregate is aware of pre-congestion for > any of his already admitted aggregates. If there is no > pre-congestion, the flow can be admitted with little > risk. " >=20 > I prefer to be explicit here, as I don't think the options > are just "being optimistic" or "probing". > ------------------------------------------------------------ >=20 > 3rd paragraph >=20 > "The PCN-ingress-node explicitly determines, before admitting > the prospective new flow, whether the ingress-egress- > aggregate can support it." >=20 > I'd suggest to add: >=20 > "If necessary, the PCN-ingress-node...." >=20 > I don't completely object to probing as long as I'm not sure > that all options avoiding it have been explored. I'd like to > make sure that it is a "last resort". That's why I prefer to > have the statements on probing to be less "binary", just > leaving you with an on/off decision. > ------------------------------------------------------------- >=20 > 7.2. Probing functions >=20 > Please change first bullet point to: >=20 > " Make decision that probing is needed. As described above, > this is when the ingress-egress-aggregate or the ECMP path > is likely to carry no PCN-traffic." > ^^^^^^^^^^^^^^^^^^ > -------------------------------------------------------------- >=20 > 2nd bullet point >=20 > Please change to: >=20 > " (if required) Communicate the request that probing is needed > - the PCN-egress-node signals to the PCN-ingress-node that > probing is needed (or the other way around). > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > The ingress could also indicate that probing is required and > will start to the egress. > -------------------------------------------------------------- >=20 > 7.3. Discussion of rationale for probing, its downsides > and open issues >=20 > I don't agree to the negative statement on the PCN coloured > signaling messages (mentioned in third viewpoint). Given that > an ECMP algorithm is limited to evaluate addresses, PCN > coloured per flow signaling messages are good means to avoid > unnecessary termination of admitted flows. The signalling > packet is received with a congestion mark, and the new flow > is blocked. This method solves downside issues of the other > two viewpoints - it is just a single packet transmitted via > a link approaching the upper rate. So it is unlikly that it > causes admitted flows to be terminated. > Note that I don't regard this as probing, as the signaling > message is transmitted anyway. > --------------------------------------------------------------- >=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 Thu Dec 13 08:16: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 1J2nvX-0008Dc-HL; Thu, 13 Dec 2007 08:16:35 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2nvW-00088t-4e for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 08:16:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nvV-00087R-OC for pcn@ietf.org; Thu, 13 Dec 2007 08:16:33 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2nvS-0001RK-VU for pcn@ietf.org; Thu, 13 Dec 2007 08:16:33 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 13:16:44 +0000 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, 13 Dec 2007 13:16:44 +0000 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 1197551786272; Thu, 13 Dec 2007 13:16:26 +0000 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 lBDDG6QR013695; Thu, 13 Dec 2007 13:16:09 GMT Message-Id: <5.2.1.1.2.20071213123527.0231f5e0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 13 Dec 2007 13:16:28 +0000 To: "Ingemar Johansson S" From: Bob Briscoe Subject: RE: [PCN] Re: ECN support in a PCN domain In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0506579B9B@esealmw109.eemea. ericsson.se> References: <002801c834e4$b1237d20$0100c80a@comm.ad.roke.co.uk> <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de> <4751B463.1050107@ericsson.com> <002801c834e4$b1237d20$0100c80a@comm.ad.roke.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: 13 Dec 2007 13:16:44.0096 (UTC) FILETIME=[6813AC00:01C83D8A] X-Spam-Score: -1.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 Ingemar, You're right that we must ensure that standards activity understands the research that has been done in a field before inventing solutions. As your MSc students found, there is little work on using ECN with CDMA or 802.11 specifically. But they missed this collection of work that goes into exactly what might be congested on the up-link and down-link and how resource sharing of the radio link should interact with e2e congestion control (using ECN): (the Mobicom paper is probably most relevant) There's also Mung Chang et al's work on cross-layer optimisation, which sets the architectural scene very well. It requires some interpretation for a standards audience: I should add that none of these are specifically about multi-rate adaptive apps. I've also not listed any refs to the considerable body of work on using ECN to distinguish transmission losses from congestion, which is a more specific subject-area than we need here. Bob At 19:52 03/12/2007, Ingemar Johansson S wrote: >Hi > >Because of the discussion of the possible use of ECN for other things >than TCP, below a collection of refrences with potential use cases that >perhaps highlights the benefits of being able to keep ECN transparent >end2end even through a PCN domain without the need to downgrade to best >effort or something similar. > >Regards >Ingemar >========================= >Thesis reports: >Fredrik Hultin >"Congestion notification and rate-adaptation for real-time services in >All-IP radio networks" >http://epubl.ltu.se/1402-1617/2007/244/LTU-EX-07244-SE.pdf >Sarker, A.N.M. Zaheduzzaman >"A study on adaptive real time video over LTE " >http://epubl.ltu.se/1653-0187/2007/064/LTU-PB-EX-07064-SE.pdf >The two thesis reports was written in parallel where the first dealt >with the network and the second dealt with the application. > >There is also ongoing some work regarding this in 3GPP, below a >collection of documents that may be of interest. >S4-070563:Real-time adaptive communication services in LTE > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_45/Docs/S4-070563.zip >Mentions only the word "congestion warning" but refers to... >S2-073328:Rate adaptation with "MBR>GBR bearers" > >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_59_Helsinki/Docs/S2-073328 >.zip >Describes how ECN can be used for MBR<->GBR bearers > >Additionally: >S2-075184: >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518 >4.zip >S2-075185: >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Docs/S2-07518 >5.zip >Latest documents in 3GPP RAN2 that deals with the use of ECN >========================= > > > > -----Original Message----- > > From: Robert Hancock [mailto:robert.hancock@roke.co.uk] > > Sent: den 2 december 2007 05:10 > > To: Magnus Westerlund; 'Lars Eggert' > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Re: ECN support in a PCN domain > > > > hi, > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Lars Eggert skrev: > > > > (I saw the idea in Robert's recent email of "downgrading" > > > ECN-enabled > > > > flows into the best-effort class of PCN. I need to think > > more about > > > > this, but on first glance this looks like a pretty elegant > > > resolution. > > > > A flow that is ECN-enabled has basically announced to the > > > network that > > > > it will react to loss in some way, i.e., probably has > > some form of > > > > congestion control. But I need to think about this more.) > > > > > > > > > > Well, that assumes that you never want to run ECN on something that > > > uses PCN. I think that assumption is wrong. A use case for PCN is > > > within a cellular core network. Where you use PCN to ensure > > that your > > > voice traffic get the best possible QoS through the core > > network. Even > > > in such a situation you have wireless links that you can't > > provide any > > > guarantees for and congestion may arise. To my knowledge ECN isn't > > > used yet but could be. > > > > > > I wished we where on clearer ground when it comes to real-time ECN > > > usage. > > > > To be clear, I am quite happy with there being use cases for > > ECN being used with traffic that also goes through an > > admission control process for some sort of capacity > > reservation (indeed, I can think of some additional ones). I > > think the only reason ECN concepts are so closely associated > > with TCP is the relative lack of other sorts of traffic in > > the wild until quite recently. > > > > So, the point is not to claim that ECN and PCN should never > > be used together. Rather, it's to suggest that if it's the > > case that even *if* it's impossible to find a PCN solution which both > > - is simple enough to get initial deployment, and > > - avoids trampling the ECN bits > > then there is still a case for a simple PCN solution which > > only helps non-ECN traffic if it also does no harm to ECN traffic. > > PCN will be better than nothing for some traffic, and not > > worse than the status quo for everything else. A PCN solution > > which is better than nothing for all traffic could be a > > subsequent evolution. > > > > (Really I guess this is all a discussion about whether there > > are simple, feasible solutions which 'cleanly integrate with > > ECN' in the language of the charter.) > > > > robert h. > > > > > > > > > > _______________________________________________ > > 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 ____________________________________________________________________________ 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 Dec 13 08:48: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 1J2oQp-0000hU-7w; Thu, 13 Dec 2007 08:48:55 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2oQn-0000gl-KT for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 08:48:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oQn-0000gO-81 for pcn@ietf.org; Thu, 13 Dec 2007 08:48:53 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2oQm-0003z1-5e for pcn@ietf.org; Thu, 13 Dec 2007 08:48:53 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F1FC3207AE; Thu, 13 Dec 2007 14:48:50 +0100 (CET) X-AuditID: c1b4fb3c-b0f99bb0000030cf-c3-47613842e8f4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DAE2A20668; Thu, 13 Dec 2007 14:48:50 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:48:50 +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: ECN support in a PCN domain Date: Thu, 13 Dec 2007 14:48:49 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05066B7D40@esealmw109.eemea.ericsson.se> In-Reply-To: <5.2.1.1.2.20071213120528.04020da0@pop3.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: ECN support in a PCN domain Thread-Index: Acg9hKua4CFqv7FhQbK7gc4KlNtabwACW37w References: <002801c834e4$b1237d20$0100c80a@comm.ad.roke.co.uk> <1B6169C658325341A3B8066E23919E1C4C156E@S4DE8PSAANK.mitte.t-com.de> <4751B463.1050107@ericsson.com> <002801c834e4$b1237d20$0100c80a@comm.ad.roke.co.uk> <5.2.1.1.2.20071213120528.04020da0@pop3.jungle.bt.co.uk> From: "Ingemar Johansson S" To: "Bob Briscoe" X-OriginalArrivalTime: 13 Dec 2007 13:48:50.0689 (UTC) FILETIME=[E46A6F10:01C83D8E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 I can verify that the abbreviations below are correct. Ingemar =20 > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 > Sent: den 13 december 2007 13:35 > To: Ingemar Johansson S > Cc: pcn@ietf.org > Subject: RE: [PCN] Re: ECN support in a PCN domain >=20 > Ingemar, >=20 > I've now read the 3GPP refs below. I just wanted to list the=20 > translations of the abbreviations I had to look up, both as a=20 > service to anyone else trying to read the 3GPP docs who=20 > doesn't come from a 3GPP background :) and to ask you to=20 > check I'm got them correct... >=20 > GBR guaranteed bit rate > MBR maximum bit rate > AMBR aggregate maximum bit rate > OBR offered bit rate >=20 > AMR adaptive multirate > PSS packet-switched streaming service >=20 > EPS evolved packet service (=3D system architecture evolution=20 > (SAE)) EPC evolved packet core MTSI multimedia telephony=20 > service for IMS (IP Multimedia Subsystem) >=20 > eNB enhanced node B (base station) >=20 > FFS for further/future study >=20 > --- > Sorry the list isn't exhaustive - there were more that I=20 > haven't listed 'cos I knew them already. >=20 >=20 >=20 > Bob >=20 > At 19:52 03/12/2007, Ingemar Johansson S wrote: > >Hi > > > >Because of the discussion of the possible use of ECN for other things > >than TCP, below a collection of refrences with potential use=20 > cases that > >perhaps highlights the benefits of being able to keep ECN transparent > >end2end even through a PCN domain without the need to=20 > downgrade to best > >effort or something similar. > > > >Regards > >Ingemar > = >=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 > >Thesis reports: > >Fredrik Hultin > >"Congestion notification and rate-adaptation for real-time=20 > services in > >All-IP radio networks" > >http://epubl.ltu.se/1402-1617/2007/244/LTU-EX-07244-SE.pdf > >Sarker, A.N.M. Zaheduzzaman > >"A study on adaptive real time video over LTE " > >http://epubl.ltu.se/1653-0187/2007/064/LTU-PB-EX-07064-SE.pdf > >The two thesis reports was written in parallel where the first dealt > >with the network and the second dealt with the application. > > > >There is also ongoing some work regarding this in 3GPP, below a > >collection of documents that may be of interest. > >S4-070563:Real-time adaptive communication services in LTE > > =20 > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_45/Docs/S4-070563.zip > >Mentions only the word "congestion warning" but refers to... > >S2-073328:Rate adaptation with "MBR>GBR bearers" > > > >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_59_Helsinki/Doc > s/S2-073328 > >.zip > >Describes how ECN can be used for MBR<->GBR bearers > > > >Additionally: > >S2-075184: > >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Do > cs/S2-07518 > >4.zip > >S2-075185: > >http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_61_Ljubljana/Do > cs/S2-07518 > >5.zip > >Latest documents in 3GPP RAN2 that deals with the use of ECN > = >=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 > > > > > > > -----Original Message----- > > > From: Robert Hancock [mailto:robert.hancock@roke.co.uk] > > > Sent: den 2 december 2007 05:10 > > > To: Magnus Westerlund; 'Lars Eggert' > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Re: ECN support in a PCN domain > > > > > > hi, > > > > > > > -----Original Message----- > > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > > Lars Eggert skrev: > > > > > (I saw the idea in Robert's recent email of "downgrading" > > > > ECN-enabled > > > > > flows into the best-effort class of PCN. I need to think > > > more about > > > > > this, but on first glance this looks like a pretty elegant > > > > resolution. > > > > > A flow that is ECN-enabled has basically announced to the > > > > network that > > > > > it will react to loss in some way, i.e., probably has > > > some form of > > > > > congestion control. But I need to think about this more.) > > > > > > > > > > > > > Well, that assumes that you never want to run ECN on=20 > something that > > > > uses PCN. I think that assumption is wrong. A use case=20 > for PCN is > > > > within a cellular core network. Where you use PCN to ensure > > > that your > > > > voice traffic get the best possible QoS through the core > > > network. Even > > > > in such a situation you have wireless links that you can't > > > provide any > > > > guarantees for and congestion may arise. To my=20 > knowledge ECN isn't > > > > used yet but could be. > > > > > > > > I wished we where on clearer ground when it comes to=20 > real-time ECN > > > > usage. > > > > > > To be clear, I am quite happy with there being use cases for > > > ECN being used with traffic that also goes through an > > > admission control process for some sort of capacity > > > reservation (indeed, I can think of some additional ones). I > > > think the only reason ECN concepts are so closely associated > > > with TCP is the relative lack of other sorts of traffic in > > > the wild until quite recently. > > > > > > So, the point is not to claim that ECN and PCN should never > > > be used together. Rather, it's to suggest that if it's the > > > case that even *if* it's impossible to find a PCN=20 > solution which both > > > - is simple enough to get initial deployment, and > > > - avoids trampling the ECN bits > > > then there is still a case for a simple PCN solution which > > > only helps non-ECN traffic if it also does no harm to ECN traffic. > > > PCN will be better than nothing for some traffic, and not > > > worse than the status quo for everything else. A PCN solution > > > which is better than nothing for all traffic could be a > > > subsequent evolution. > > > > > > (Really I guess this is all a discussion about whether there > > > are simple, feasible solutions which 'cleanly integrate with > > > ECN' in the language of the charter.) > > > > > > robert h. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 >=20 > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research=20 > Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 > +44 1473 645196=20 >=20 >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 13 09:34:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2p8z-0007rJ-AA; Thu, 13 Dec 2007 09:34:33 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2p8x-0007qH-4o for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 09:34:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2p8w-0007q6-Pr for pcn@ietf.org; Thu, 13 Dec 2007 09:34:30 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2p8w-00056d-7f for pcn@ietf.org; Thu, 13 Dec 2007 09:34:30 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lBDEY4jj011123; Thu, 13 Dec 2007 15:34:21 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <000201c83ca8$cca448b0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B3440D@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] Questions on probing Date: Thu, 13 Dec 2007 15:33:58 +0100 Message-ID: <001901c83d95$39157c70$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acg8I3VTGuNG3yt8Qaum9ZZ2LdiYPgAg/qUgADcQwSAABBu7QA== In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3440D@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.087 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 13 Dec 2007 15:34:21 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 My point is that I do not agree that the below bullet breaks Assumption 3 (aggregation). This depends on how the algorithm is implemented and I thought that the architectural draft should not describe implementation steps. > o Simply admitting the new flow has a significant risk of leading to > overload, because the PCN-domain reaches out towards the end > terminals where link capacity is low. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: donderdag 13 december 2007 13:34 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] Questions on probing > > Hi Georgios > To pick up on our of your comments, which concerns the archit draft > > > > > "The first point breaks Assumption 3 (aggregation) and hence means > that > > this > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > I do not agree with this conclusion, since I do not agree with the > > argumentation that the first point breaks Assumption 3 more > than the > > situation that no probing is used during admission control. > > Therefore, please remove the sentence: > > "The first point breaks Assumption 3 (aggregation) and hence means > that > > this > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > I don't understand your comment, and wonder if it's just that > the section is not very clear about the context of the draft > at this point. > > the third viewpoint on 'why do probing' is simply 'admission > control is always done by probing'. It assumes the following: > > o Simply admitting the new flow has a significant risk of > leading to > overload, because the PCN-domain reaches out towards the end > terminals where link capacity is low. > > o Every admission control decision involves probing, using the > signalling set-up message as the probe packet (eg RSVP PATH). > > o The PCN-marking behaviour is such that every packet is > PCN-marked > if the flow should be blocked, hence only a single > probing packet > is needed. > > I think the first of these bullets breaks Assumption 3 > (aggregation) and hence means that this viewpoint is out of > scope of the initial Charter of the PCN WG. > > phil > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 13 09:45: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 1J2pK0-0003bl-C1; Thu, 13 Dec 2007 09:45:56 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2pJz-0003bP-45 for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 09:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pJy-0003bF-QJ for pcn@ietf.org; Thu, 13 Dec 2007 09:45:54 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2pJv-0004NC-3L for pcn@ietf.org; Thu, 13 Dec 2007 09:45:54 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:46:04 +0000 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] Questions on probing Date: Thu, 13 Dec 2007 14:46:03 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34413@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <001901c83d95$39157c70$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing thread-index: Acg8I3VTGuNG3yt8Qaum9ZZ2LdiYPgAg/qUgADcQwSAABBu7QAAAY0ag From: To: , , X-OriginalArrivalTime: 13 Dec 2007 14:46:04.0617 (UTC) FILETIME=[E3324390:01C83D96] X-Spam-Score: -1.0 (-) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 I don't see why this depends on implementation. Surely it depends on the scenario. The scenario I was thinking of was where the PCN-domain reaches out towards the end terminals where link capacity is low. (Well that could be better written - it's possible that there might be high link capacity near the end terminals, but normally link cap is lower near the edge.) Low link cap, in general, breaks the aggregation assumption. Now there're some people who have in mind using PCN in such scenarios, and doing adm ctrl by probing (for all new flows). The text does not make any judgement about whether such an approach is feasible, merely that it's out of the current scope. phil > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 13 December 2007 14:34 > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] Questions on probing >=20 > Hi Phil >=20 > My point is that I do not agree that the below bullet > breaks Assumption 3 (aggregation). This depends on how the algorithm is > implemented and I thought that the architectural draft should not describe > implementation steps. >=20 > > o Simply admitting the new flow has a significant risk of leading to > > overload, because the PCN-domain reaches out towards the end > > terminals where link capacity is low. >=20 > Best regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: donderdag 13 december 2007 13:34 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > Hi Georgios > > To pick up on our of your comments, which concerns the archit draft > > > > > > > > "The first point breaks Assumption 3 (aggregation) and hence means > > that > > > this > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > I do not agree with this conclusion, since I do not agree with the > > > argumentation that the first point breaks Assumption 3 more > > than the > > > situation that no probing is used during admission control. > > > Therefore, please remove the sentence: > > > "The first point breaks Assumption 3 (aggregation) and hence means > > that > > > this > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > I don't understand your comment, and wonder if it's just that > > the section is not very clear about the context of the draft > > at this point. > > > > the third viewpoint on 'why do probing' is simply 'admission > > control is always done by probing'. It assumes the following: > > > > o Simply admitting the new flow has a significant risk of > > leading to > > overload, because the PCN-domain reaches out towards the end > > terminals where link capacity is low. > > > > o Every admission control decision involves probing, using the > > signalling set-up message as the probe packet (eg RSVP PATH). > > > > o The PCN-marking behaviour is such that every packet is > > PCN-marked > > if the flow should be blocked, hence only a single > > probing packet > > is needed. > > > > I think the first of these bullets breaks Assumption 3 > > (aggregation) and hence means that this viewpoint is out of > > scope of the initial Charter of the PCN WG. > > > > phil > > >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 13 10:25: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 1J2pvo-0007Zn-8A; Thu, 13 Dec 2007 10:25:00 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2pvn-0007Zi-86 for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 10:24:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pvm-0007Za-Sh for pcn@ietf.org; Thu, 13 Dec 2007 10:24:58 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2pvl-0007eA-Sy for pcn@ietf.org; Thu, 13 Dec 2007 10:24:58 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 15:25:11 +0000 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] A two-layer approach for PCN Date: Thu, 13 Dec 2007 15:25:10 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34414@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <475F09D2.9030804@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] A two-layer approach for PCN thread-index: Acg8QdmkdRhCyIpFTm+Zy4WTlHsaMgBWHBFA From: To: , X-OriginalArrivalTime: 13 Dec 2007 15:25:11.0374 (UTC) FILETIME=[59F8F6E0:01C83D9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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 Michael Michael, Thanks for this. I'll work some clarification into the Arch draft on the lines of the first half of your email (probably without introducing any new terms & abbreviations). The second part about examples of marking and edge behaviours I don't think is needed, as already elsewhere or planned to be. The marking behaviour is hinted at in the doc, and is captured fully in the charny comparison draft. The edge behaviours again I think is hinted at, and will come out further during work on that milestone. Your comments made me realise that the list of bullets (in the Intro fo the draft) preceded by "Several deployment models are possible:" actually includes several different types of things - different signalling architectures, diff OAM issues, diff data plane issues. So I'll try & tidy this all up and also mention the 3 'edge behaviour' cases you talk about (though probably in less detail) Next version of arch draft will be until after Christmas, probably end of Jan.=20 Ps In the meantime, we're also thinking more about ECN-PCN interactions, so there should be some better text about that as well. Thanks Phil/ > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 11 December 2007 22:06 > To: pcn > Subject: [PCN] A two-layer approach for PCN >=20 > Hi all, >=20 > during last week's meeting I had discussions with many people regarding > a separation of packet marking vs. admission control and flow > termination aspects. The intention was to make the structure of PCN more > obvious and to facilitate its adaptation to various network > architectures. The following text reflects the outcome of these > discussions. >=20 > Comments are welcome. >=20 > Regards, >=20 > Michael >=20 > -- >=20 > The pre-congestion notification (PCN) architecture consists of two > different layers: the packet marking layer (PML) and the admission > control and flow termination layer (ACFTL). > The packet marking layer (PML) describes how PCN-capable interior nodes > meter and mark PCN packets. Within a single network only one packet > marking layer (PML) MUST be deployed, i.e. PCN-capable interior nodes > MUST implement the same metering and marking behavior for all links. The > admission control and flow termination layer (ACFTL) describes how PCN > edge nodes make use of the packet markings observed by the PCN egress > node to decide whether new flows can be accepted or whether already > admitted flows need to be terminated. The implementation of the > admission control and flow termination layer (ACFTL) may take advantage > of specific transport architectures and may be tailored for various > signaling architectures with which it needs to interoperate. In contrast > to the packet marking layer (PML), different instances admission control > and flow termination layers (ACFTL) MAY be used in the same network as > long as they interpret the semantics of the packet markings in the same > way and don't lead to unfairness issues. >=20 >=20 > +---+---+---+---+ > | A | A | . | A | > | C | C | . | C | > | F | F | . | F | > | T | T | . | T | > | L | L | . | L | > | | | | | > | 0 | 1 | . | n | > +---+---+---+---+ > | PML | > +---------------+ >=20 > Figure 1: Within a single network, only one packet marking layer (PML) > MUST be deployed, but several admission control and flow > termination layers (ACFTL) MAY coexist. >=20 > In the following, the concepts of the packet marking layer (PML) and > admission control and flow termination layer (ACFTL) are briefly > illustrated. >=20 > 4 examples of mutually exclusive interior node behaviors for > implementation of the PML: >=20 > a) Ramp marking based on the admissible rate and excess-rate marking > based on the supportable rate (CL proposal) > b) Threshold marking based on the admissible rate and excess-rate > marking with marking frequency reduction based on the supportable rate > (3sm proposal) > c) Threshold marking based on the admissible rate and excess-rate > marking based on the supportable rate (behavioral intersection of CL and > 3sm proposal) > d) Excess rate marking based on the admissible rate (Single Marking > proposal) >=20 > Note that only one packet marking layer (PML) can be deployed within a > single network. >=20 >=20 > 3 examples for different edge node behaviors for implementation of the > admission control and flow termination layer (ACFTL) based on the packet > marking layer b) above: >=20 > o E3Tunnel > Given: edge-to-edge MPLS tunnels; > Egress node measures CLE for tunnel and depending on that value, it > sends an "admission-stop" or "admission-continue" message to the > corresponding ingress node that then stops or continues admitting > further flows. > Flows are terminated when one of its packets was ET-marked. > o End2PS > Given: end-to-end on-path signalling protocol; > PCN egress node is a RSVP capable node and returns PATHERR if first > PATH msg was "admission-stop" marked; PCN ingress node accepts all flows > whose RESV messages come through. > Flows are terminated when one of its packets was ET-marked: the PCN > egress node sends a RESVTEAR message to the PCN ingress. > o Centralized node > Given: centralized node (CN) in charge of admitting or terminating > flows; > Upon a new flow arrival, the CN issues an admission request to PCN > ingress node for a future data flow with an indicated source-destination > tuple; > CN sends a probe packet to the PCN egress node which returns the > probe to the CN; the CN rejects the flow if probe was marked and admits > it if probe was unmarked. > Flows are terminated when one of its packets was ET-marked. The PCN > egress node sends the marked packet to the CN which terminated the > corresponding flow. >=20 > These admission control and flow termination layers (ACFTL) MAY > simultaneously be applied in the same network. Similar methods can be > defined based on the other packet marking layers (PML) defined above. >=20 > Within the current charter, only one packet marking layer (PML) should > be standardized as well as only one admission control and flow > termination layer (ACFTL), presumably for ingress-egress aggregates. > However, it is desirable that the architecture is extensible towards > other admission control and flow termination layers (ACFTL) to address > the need of various network architectures (e.g., without explicit > aggregates, with multipath routing, with centralized control nodes, ...) > that need QoS support in the future. >=20 > Note: this text does not contradict the current version of the > architecture draft. Essentially, the packet marking behavior of interior > nodes is put into a packet marking layer and the admission control and > flow termination behavior of edge nodes is put into an admission control > and flow termination layer. The two-layer approach just makes the idea > more explicit that different edge node behaviors may be defined for a > single interior node behavior and that several edge node behaviors may > coexist in the same network if necessary. >=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 >=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 Thu Dec 13 11:07: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 1J2qan-00021U-N5; Thu, 13 Dec 2007 11:07:21 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2qam-00021O-FF for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 11:07:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qam-00021G-5b for pcn@ietf.org; Thu, 13 Dec 2007 11:07:20 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2qak-0007oj-A9 for pcn@ietf.org; Thu, 13 Dec 2007 11:07:20 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lBDG6qHI024524; Thu, 13 Dec 2007 17:07:15 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <001901c83d95$39157c70$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B34413@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] Questions on probing Date: Thu, 13 Dec 2007 17:06:45 +0100 Message-ID: <001d01c83da2$31db21a0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acg8I3VTGuNG3yt8Qaum9ZZ2LdiYPgAg/qUgADcQwSAABBu7QAAAY0agAAK3wSA= In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34413@E03MVZ1-UKDY.domain1.systemhost.net> X-Spam-Score: 0.687 () AWL,J_CHICKENPOX_52,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 13 Dec 2007 17:07:16 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Sorry, but reading the text in Section 7.3 it gives me the impression that the architecture draft is trying to get out of the PCN scope the feature that provides admission control when probing is used. The given argumentation on the aggregation issue is in my opinion only valid for some implementations/scenarios and cannot be extrapolated to cover all possible scenarios/implementations that are covered by the PCN scope. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: donderdag 13 december 2007 15:46 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] Questions on probing > > I don't see why this depends on implementation. Surely it > depends on the scenario. The scenario I was thinking of was > where the PCN-domain reaches out towards the end terminals > where link capacity is low. (Well that could be better > written - it's possible that there might be high link > capacity near the end terminals, but normally link cap is > lower near the edge.) Low link cap, in general, breaks the > aggregation assumption. > > Now there're some people who have in mind using PCN in such > scenarios, and doing adm ctrl by probing (for all new flows). > The text does not make any judgement about whether such an > approach is feasible, merely that it's out of the current scope. > > phil > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 13 December 2007 14:34 > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > Hi Phil > > > > My point is that I do not agree that the below bullet breaks > > Assumption 3 (aggregation). This depends on how the algorithm > is > > implemented and I thought that the architectural draft should not > describe > > implementation steps. > > > > > o Simply admitting the new flow has a significant risk of leading > to > > > overload, because the PCN-domain reaches out towards the end > > > terminals where link capacity is low. > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: donderdag 13 december 2007 13:34 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > pcn@ietf.org > > > Subject: RE: [PCN] Questions on probing > > > > > > Hi Georgios > > > To pick up on our of your comments, which concerns the > archit draft > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > hence means > > > that > > > > this > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > I do not agree with this conclusion, since I do not > agree with the > > > > argumentation that the first point breaks Assumption 3 more > > > than the > > > > situation that no probing is used during admission control. > > > > Therefore, please remove the sentence: > > > > "The first point breaks Assumption 3 (aggregation) and > hence means > > > that > > > > this > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > > > I don't understand your comment, and wonder if it's just that the > > > section is not very clear about the context of the draft at this > > > point. > > > > > > the third viewpoint on 'why do probing' is simply > 'admission control > > > is always done by probing'. It assumes the following: > > > > > > o Simply admitting the new flow has a significant risk of > > > leading to > > > overload, because the PCN-domain reaches out towards the end > > > terminals where link capacity is low. > > > > > > o Every admission control decision involves probing, using the > > > signalling set-up message as the probe packet (eg > RSVP PATH). > > > > > > o The PCN-marking behaviour is such that every packet is > > > PCN-marked > > > if the flow should be blocked, hence only a single probing > > > packet > > > is needed. > > > > > > I think the first of these bullets breaks Assumption 3 > > > (aggregation) and hence means that this viewpoint is out > of scope of > > > the initial Charter of the PCN WG. > > > > > > phil > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Dec 13 11:44:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rAg-00042q-1D; Thu, 13 Dec 2007 11:44:26 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J2rAe-00042e-Fm for pcn-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 11:44:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rAe-00042U-4c for pcn@ietf.org; Thu, 13 Dec 2007 11:44:24 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2rAd-0001b9-8N for pcn@ietf.org; Thu, 13 Dec 2007 11:44:23 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 16:44:37 +0000 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] Questions on probing Date: Thu, 13 Dec 2007 16:44:36 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34417@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <001d01c83da2$31db21a0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on probing thread-index: Acg8I3VTGuNG3yt8Qaum9ZZ2LdiYPgAg/qUgADcQwSAABBu7QAAAY0agAAK3wSAAAVwnUA== From: To: , , X-OriginalArrivalTime: 13 Dec 2007 16:44:37.0018 (UTC) FILETIME=[728487A0:01C83DA7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 Great, we're in violent agreement that I need to clarify this! > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 13 December 2007 16:07 > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] Questions on probing >=20 > Hi Phil >=20 > Sorry, but reading the text in Section 7.3 it gives me the impression that > the architecture draft is trying to get out of the PCN scope the feature > that provides > admission control when probing is used. >=20 > The given argumentation on the aggregation issue is in my opinion only > valid > for some > implementations/scenarios and cannot be extrapolated to cover all possible > scenarios/implementations > that are covered by the PCN scope. >=20 > Best regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: donderdag 13 december 2007 15:46 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > I don't see why this depends on implementation. Surely it > > depends on the scenario. The scenario I was thinking of was > > where the PCN-domain reaches out towards the end terminals > > where link capacity is low. (Well that could be better > > written - it's possible that there might be high link > > capacity near the end terminals, but normally link cap is > > lower near the edge.) Low link cap, in general, breaks the > > aggregation assumption. > > > > Now there're some people who have in mind using PCN in such > > scenarios, and doing adm ctrl by probing (for all new flows). > > The text does not make any judgement about whether such an > > approach is feasible, merely that it's out of the current scope. > > > > phil > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 13 December 2007 14:34 > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > pcn@ietf.org > > > Subject: RE: [PCN] Questions on probing > > > > > > Hi Phil > > > > > > My point is that I do not agree that the below bullet breaks > > > Assumption 3 (aggregation). This depends on how the algorithm > > is > > > implemented and I thought that the architectural draft should not > > describe > > > implementation steps. > > > > > > > o Simply admitting the new flow has a significant risk of leading > > to > > > > overload, because the PCN-domain reaches out towards the end > > > > terminals where link capacity is low. > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > Sent: donderdag 13 december 2007 13:34 > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > pcn@ietf.org > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > Hi Georgios > > > > To pick up on our of your comments, which concerns the > > archit draft > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > hence means > > > > that > > > > > this > > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > > > I do not agree with this conclusion, since I do not > > agree with the > > > > > argumentation that the first point breaks Assumption 3 more > > > > than the > > > > > situation that no probing is used during admission control. > > > > > Therefore, please remove the sentence: > > > > > "The first point breaks Assumption 3 (aggregation) and > > hence means > > > > that > > > > > this > > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > > > > > > I don't understand your comment, and wonder if it's just that the > > > > section is not very clear about the context of the draft at this > > > > point. > > > > > > > > the third viewpoint on 'why do probing' is simply > > 'admission control > > > > is always done by probing'. It assumes the following: > > > > > > > > o Simply admitting the new flow has a significant risk of > > > > leading to > > > > overload, because the PCN-domain reaches out towards the end > > > > terminals where link capacity is low. > > > > > > > > o Every admission control decision involves probing, using the > > > > signalling set-up message as the probe packet (eg > > RSVP PATH). > > > > > > > > o The PCN-marking behaviour is such that every packet is > > > > PCN-marked > > > > if the flow should be blocked, hence only a single probing > > > > packet > > > > is needed. > > > > > > > > I think the first of these bullets breaks Assumption 3 > > > > (aggregation) and hence means that this viewpoint is out > > of scope of > > > > the initial Charter of the PCN WG. > > > > > > > > phil > > > > > > > > > >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 14 05:23: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 1J37hL-00036F-L5; Fri, 14 Dec 2007 05:23:15 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J37hK-0002pi-2j for pcn-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 05:23:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J37hJ-0002oU-OK for pcn@ietf.org; Fri, 14 Dec 2007 05:23:13 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J37hI-000158-Rn for pcn@ietf.org; Fri, 14 Dec 2007 05:23:13 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lBEAMiC6010239; Fri, 14 Dec 2007 11:23:07 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <001d01c83da2$31db21a0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B34417@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] Questions on probing Date: Fri, 14 Dec 2007 11:22:39 +0100 Message-ID: <001201c83e3b$48b9ae20$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34417@E03MVZ1-UKDY.domain1.systemhost.net> thread-index: Acg8I3VTGuNG3yt8Qaum9ZZ2LdiYPgAg/qUgADcQwSAABBu7QAAAY0agAAK3wSAAAVwnUAAlTBZg X-Spam-Score: 0.687 () AWL,J_CHICKENPOX_52,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 14 Dec 2007 11:23:07 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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 Great! Thank you very much! Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: donderdag 13 december 2007 17:45 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] Questions on probing > > Great, we're in violent agreement that I need to clarify this! > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 13 December 2007 16:07 > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > pcn@ietf.org > > Subject: RE: [PCN] Questions on probing > > > > Hi Phil > > > > Sorry, but reading the text in Section 7.3 it gives me the > impression > that > > the architecture draft is trying to get out of the PCN scope the > feature > > that provides > > admission control when probing is used. > > > > The given argumentation on the aggregation issue is in my > opinion only > > valid for some implementations/scenarios and cannot be > extrapolated to > > cover all > possible > > scenarios/implementations > > that are covered by the PCN scope. > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: donderdag 13 december 2007 15:46 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > pcn@ietf.org > > > Subject: RE: [PCN] Questions on probing > > > > > > I don't see why this depends on implementation. Surely it > depends on > > > the scenario. The scenario I was thinking of was where the > > > PCN-domain reaches out towards the end terminals where > link capacity > > > is low. (Well that could be better written - it's possible that > > > there might be high link capacity near the end terminals, but > > > normally link cap is lower near the edge.) Low link cap, > in general, > > > breaks the aggregation assumption. > > > > > > Now there're some people who have in mind using PCN in such > > > scenarios, and doing adm ctrl by probing (for all new flows). > > > The text does not make any judgement about whether such > an approach > > > is feasible, merely that it's out of the current scope. > > > > > > phil > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: 13 December 2007 14:34 > > > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com; > > > pcn@ietf.org > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > Hi Phil > > > > > > > > My point is that I do not agree that the below bullet breaks > > > > Assumption 3 (aggregation). This depends on how the algorithm > > > is > > > > implemented and I thought that the architectural draft > should not > > > describe > > > > implementation steps. > > > > > > > > > o Simply admitting the new flow has a significant risk of > leading > > > to > > > > > overload, because the PCN-domain reaches out towards the end > > > > > terminals where link capacity is low. > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > > > Sent: donderdag 13 december 2007 13:34 > > > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com; > > > pcn@ietf.org > > > > > Subject: RE: [PCN] Questions on probing > > > > > > > > > > Hi Georgios > > > > > To pick up on our of your comments, which concerns the > > > archit draft > > > > > > > > > > > > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > hence means > > > > > that > > > > > > this > > > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > > > > > I do not agree with this conclusion, since I do not > > > agree with the > > > > > > argumentation that the first point breaks Assumption 3 more > > > > > than the > > > > > > situation that no probing is used during admission control. > > > > > > Therefore, please remove the sentence: > > > > > > "The first point breaks Assumption 3 (aggregation) and > > > hence means > > > > > that > > > > > > this > > > > > > viewpoint is out of scope of initial Charter of the PCN WG." > > > > > > > > > > > > > > > > I don't understand your comment, and wonder if it's just that > the > > > > > section is not very clear about the context of the > draft at this > > > > > point. > > > > > > > > > > the third viewpoint on 'why do probing' is simply > > > 'admission control > > > > > is always done by probing'. It assumes the following: > > > > > > > > > > o Simply admitting the new flow has a significant risk of > > > > > leading to > > > > > overload, because the PCN-domain reaches out towards the > end > > > > > terminals where link capacity is low. > > > > > > > > > > o Every admission control decision involves probing, using > the > > > > > signalling set-up message as the probe packet (eg > > > RSVP PATH). > > > > > > > > > > o The PCN-marking behaviour is such that every packet is > > > > > PCN-marked > > > > > if the flow should be blocked, hence only a > single probing > > > > > packet > > > > > is needed. > > > > > > > > > > I think the first of these bullets breaks Assumption 3 > > > > > (aggregation) and hence means that this viewpoint is out > > > of scope of > > > > > the initial Charter of the PCN WG. > > > > > > > > > > phil > > > > > > > > > > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Dec 14 11:38: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 1J3DYf-0004Zj-H9; Fri, 14 Dec 2007 11:38:41 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J3DYe-0004Ze-OP for pcn-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 11:38:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3DYe-0004ZW-DJ for pcn@ietf.org; Fri, 14 Dec 2007 11:38:40 -0500 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 1J3DYd-0002ch-O0 for pcn@ietf.org; Fri, 14 Dec 2007 11:38:40 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9EC21C648; Fri, 14 Dec 2007 17:38:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 91F0EC661; Fri, 14 Dec 2007 17:38:36 +0100 (CET) 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 61776C648; Fri, 14 Dec 2007 17:38:35 +0100 (CET) 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 lBEGcZM06493; Fri, 14 Dec 2007 17:38:35 +0100 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 674E16F591; Fri, 14 Dec 2007 17:30:33 +0100 (CET) Message-ID: <4762B1FF.1040008@informatik.uni-wuerzburg.de> Date: Fri, 14 Dec 2007 17:40:31 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francois Le Faucheur Subject: Re: [PCN] Few suggestions/comments on draft-charny-pcn-comparison References: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> In-Reply-To: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.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: 25620135586de10c627e3628c432b04a Cc: PCN IETF 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 Francois, see inline, please! Francois Le Faucheur wrote: > Hello, > > A few suggestions/comments (from a quick read): > > * I found sections 1-10 of this document very helpful to try get > my head around the various approaches in a consistent/comprehensive > manner. I hope this document continues to be progressed. > > * While I understand the document does not (yet) try to weigh the > different "comparison Criteria", I think it would be worth pointing > out a few salient points like: > (i) when discussing/comparing the "type of metering & > marking": it may be worth pointing out that "Excess-rate-marking" is a > very common mechanism supported on many (if not all) modern router > Hardware today, while any other metering/marking flavor is probably > not so commonly supported today. This seems like a significant > consideration with respect to possible PCN introduction. > (ii) when discussing/comparing the "rate measurement at > boundary nodes": it may be worth pointing out that a scheme that does > NOT require "rate measurement at boundary nodes" would result in > considerable simplification. > (iii) when discussing "parameter configuration", the I-D > only discusses the "network-wide" parameters (that are only applicable > to SM). Thus, it kind-of suggests that SM may be a little more complex > to configure than the other schemes. However, the I-D omits to discuss > all the other parameters that are likely to be much much harder to > fine-tune (probably making the configuration of the single SM > network-wide parameter appear as piece of cake). Those other > parameters should also be discussed. > > * when discussing 3SM (in section 4.3 and section 9), it would be > very useful to characterize 3SM performance WITH and WITHOUT rate > measurement at boundary node. As stated above, if the 3SM scheme works > well without rate measurement at boundary node, that would be a > significant benefit of that scheme. However, when used without rate > measurement at boundary node, one would expect performance degradation > (depending on actual scheme this may include under-admission and/or > high signaling). I think it is the intention of the authors to include > material on this in future versions. I am looking forward to such > information helping further assess whether 3SM without rate > measurement is a viable option. Yes, you are right. This is crucial and needs to be done. We're working on this issue. Regards, Michael > > I hope this is useful. > > Francois > > > _______________________________________________ > 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 Dec 17 09:58: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 1J4HQ9-00021n-6Y; Mon, 17 Dec 2007 09:58:17 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J4HQ7-0001q8-5x for pcn-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 09:58:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4HQ6-0001oO-PY for pcn@ietf.org; Mon, 17 Dec 2007 09:58:14 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4HQ6-0001jA-GT for pcn@ietf.org; Mon, 17 Dec 2007 09:58:14 -0500 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 lBHEwBX01993 for ; Mon, 17 Dec 2007 14:58:12 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] Architecture draft- bi-directional flows Date: Mon, 17 Dec 2007 09:58:06 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB646513AA9A27@zcarhxm1.corp.nortel.com> In-Reply-To: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft- bi-directional flows Thread-Index: Acg7PeyPVSOVh7W6Rc+UHvJYp4Jh5wFfoa0Q References: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> From: "Jozef Babiarz" To: "PCN IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 In my additional review of the PCN Architecture draft, I realized that there is no mention of how bi-directional flows are handled. I believe that the PCN Architecture draft needs to discuss and explain how admission control and flow termination works at high level for telephony and video conferencing applications and that both, telephony and video conferencing applications have bi-directional flows. For admission control a new flow can not be admitted unless the traffic level on both unidirectional paths is below the PCN-lower-rate. As well for flow termination, a bi-directional flow is terminated if one of the unidirectional paths is in excess of PCN-upper-rate.=20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Dec 17 21:27: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 1J4SBK-0001aZ-7H; Mon, 17 Dec 2007 21:27:42 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J4SBI-0001Zk-UK for pcn-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 21:27:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4SBI-0001Zc-Hy for pcn@ietf.org; Mon, 17 Dec 2007 21:27:40 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4SBG-0000cH-Lt for pcn@ietf.org; Mon, 17 Dec 2007 21:27:40 -0500 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 lBI2RZ2C025814 for ; Mon, 17 Dec 2007 20:27:38 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 20:27:36 -0600 Received: from [147.117.169.126] ([147.117.169.126]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 20:27:35 -0600 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-NEs4scItMxj2hvKu3hDN" Organization: Ericsson IP Infrastructure Date: Mon, 17 Dec 2007 21:27:35 -0500 Message-Id: <1197944855.3114.65.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) X-OriginalArrivalTime: 18 Dec 2007 02:27:35.0818 (UTC) FILETIME=[8D28D6A0:01C8411D] X-Spam-Score: -4.0 (----) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Subject: [PCN] IETF 70 PCN 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 --=-NEs4scItMxj2hvKu3hDN Content-Type: text/plain Content-Transfer-Encoding: 7bit In the absence of any comments/corrections, the meeting minutes have been uploaded: http://www3.ietf.org/proceedings/07dec/minutes/pcn.txt and are attached below. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-NEs4scItMxj2hvKu3hDN Content-Disposition: attachment; filename=pcn-ietf70-minutes.txt Content-Type: text/plain; name=pcn-ietf70-minutes.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion and Pre-Congestion Notification WG (pcn) IETF 70 Meeting Minutes Monday, December 3, 2007 Vancouver, BC, Canada 1740-1950 Afternoon Session III Salon 2 ==================================== CHAIRs: Scott Bradner Steven Blake Minute taker: Tom Taylor AGENDA: o Administrivia chairs 10 min ------------------------------------------------------------------------------ - Blue sheets - Scribe - Agenda bash - Milestones status Steven presented on the working group status. Sees open issues on architecture doc -- not yet ready for WGLC. Need document for second milestone. Want one marking and encoding solution. Reviewed premises of work ("Why we are here") Chairs' assessment: get off the corner cases. Want single solutions particularly in the interior, to prevent interoperability nightmares. We have previously interpreted "inelastic flows" too narrowly. Need to be compatible with ECN and Diffserv. Need to speed things up. Operator feedback: moving in right direction, don't use too many IP header codepoints, hurry up so we can look at multi-domain Comments: --------- Anna: Have to be careful not to jeopardize multi-domain solutions. Scott: can't know everything. Keep interior marking simple, leave innovation to the edges is a proposal toward long-term validity. o Discuss open issues in draft-ietf-pcn-architecture-02 all 75 min ------------------------------------------------------------------------------ Philip: summary of progress and open issues. Joe: doesn't understand scenario where tunnel terminates within a PCN domain. Philip: more general scenario of tunnel into Diffserv domain. Joe: would we not use same protective mechanism as for Diffserv. Philip: basically same mechanism, but needed a little adaptation. Joe: but seems more reasonable to do at edge. Steven: RFC has tunnel end treated as ingress point to network. Michael M.: don't worry about this unless operators say it matters. Scott agrees. Tina: probing should be based on single message, signalling reqts dealt with in a separate draft. Steven: Probing advocated for two situations, ECMP and small aggregates. Small-aggregate reason is in his view a corner case. ECMP is interesting. Would be nice to have simple solution to that problem. Lot of security issues to probing. Imposing special reqts on router not a great way to go. AS Chair: this is where we make the decision. Michael: RSVP Scott: is there an RFC on ho to do do this? Magnus: Francois: Two drafts coming out. PCN is a different problem from the general RSVP problem. Michael: RSVP could be used to trigger admission. Anna: security one issue. Applicability of RSVP another. Issue on list was whether RSVP gives right info for ECMP case. Steven: certainly deployments where RSVP supported on ingress and egress, could then do PATH, RSVP use of PCN markings. Not in scope of PCN itself. Xiaoming: option packages dangerous for inter-domain. Elwyn (IAB view): concerned with time required to do admission control if you probe. Beginning to have serious issues with connection delay. Also concerned about trying to make external decisions on what happens on a single link. Bob: BT analyses show will get same result for repeated probes -- get time correlation, so single probe enough. Elwyn: even first probe raises issue of connection delay. Bob: in some cases can probe in parallel to signalling. Lars: what do you do with the remaining packets of a data flow that arrive while you are deciding to admit? Another issue, what impact does probing have on overall architecture. Jozef: UDP -- no feedback. (Questioned by ADs) Anna: is this a binary decision? Lars: any other way to handle ECMP? Bob: in some scenarios, don't need probing -- e.g. MPLS Anna: Steven: inconsistent to assume operator is competent to use PCN but not competent to engineer ECMP correctly. Steven: also have to think about reverse path with probing. Philip: BT has been thinking about ECMP for a while, but has failed to come up with an elegant solution. Can't predict that such a solution will emerge in next 6 months. Lars: would like to proceed without, see if any operator says it's critical. Anna: ECMP problems likely to be fixed independently. Steven as Chair: Egress discovery - is there any scenario where probing is the only way to do it? No answer. How many think we need to work on probing? ??: should be hashing Michael: not important to work on probing now, but should keep aware to allow extensibility. Scott: what needs to be in the architecture doc? How many people think we need a discussion of probing in the arch document? Kwok-Ho: question on RSVP -answered. Francois: simplicity means lowered usefulness. Jozef: matter of deployment scope whether probing should be discussed. Scott: this is an overall arch doc, what level of discussion called for Jozef: reasons for probing, not solutions ??: optional component of arch Anna: is current discussion OK? Steven: does there need to be discussion? A number of "yes". How many find current discussion necessary and sufficient? Again a number of "yes". Finds a significant number of people supporting this latter view. How many think protocol work on probing should be done right now? No one. Lars: how many think it should be done before arch draft WGLC? No one. Centralized decision-making node: Steven: is this something we need to work on? Anna: two questions -- should it be mentioned, should WG work on it? Discussion: differing views. Recognition that centralized node does not ncessarily mean new protocol. Steven: consensus that current text is sufficient on the topic. Addressing issue -- peer discovery. Philip enumerates a number of alternatives, will expand text. ECN: ---- Bob spoke in favour of classifying ECN as non-PCN Magnus: prefers ECN-compatible solution Michael: two different behaviours Discussion of whether all routers in the domain are PCN-capable. Jozef finds that unrealistic. Lars: charter assumption. Scott: matters only for routers that will experience congestion. Lars: scenario where e2e ECN would be beneficial would also be one where PPCN can help Magnus: Anna: discussion should really be informed by outcome of encoding discussion Steven: some algorithms would Lars: prefers coexistence Bob: endpoint based measurement doesn't work in some cases Magnus: trying to run below application level Steven: need more work in arch draft on ECN. Let discussion continue on list. Maybe encoding comparison will provide guidance. Philip: this is the last issue, as he sees it. Any other views? No reply. o Discuss open issues in draft-chan-pcn-encoding-comparison-01 all 45 min ------------------------------------------------------------------------------ Kwok-Ho presenting. Series of questions to simplify draft. Bob: can't see how PCN would work w/o using Diffserv codepoints. Steven: assumed that Diffserv would be used Jozef: redefine RFC 3168? Lars: really problematic. Jozef: suggested possibility: redefine behaviour of DSCP codepoint Kwok-Ho: bottom line: WG would register new DSCP codepoint with IANA. Scott: Diffserv codepoint assignments are based on Standards Track actions. Bob: thought Diffserv used locally-defined values. Anna: answered questions on slide. First two bullets, yes. Bob: trying to clarify intent of questions. Noted that whether Diffserv codepoint is used is different question from whether new codepoint should be standardized. Bob: on second bullet, replace 3.2 with para or two on how it would be impossible to do without Diffserv. Kwok-Ho: third bullet -- can out-of-band channels be eliminated from further consideration? Anna and Scott: rather than throw it away, say it will not be considered. Next chart: what indications are required. Drop Nonce indication. Agreed. Jozef: Anna: identify states. Steven: can't see fewer than three markings needed, or more than four. Philip: spoke for transition indications ??: Steven as contributor: have the draft concentrate on encodings -- where do we get the bits from? Other work can provide semantics. Discussion of whether DSCP visible end-to-end -- battle in Diffserv -- customers vs. operators. Philip: Need to say that range of states required is 3 to 5. Agreed. Next chart: criteria: Leakage-safe could be an additional criterion -- RFC 4744 Timed out. Take question of whether this is WG item to the list. --=-NEs4scItMxj2hvKu3hDN 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 --=-NEs4scItMxj2hvKu3hDN-- From pcn-bounces@ietf.org Tue Dec 18 08:59: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 1J4czG-0005Pr-Nq; Tue, 18 Dec 2007 08:59:58 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J4czG-0005OU-6H for pcn-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 08:59:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4czF-0005OL-SP for pcn@ietf.org; Tue, 18 Dec 2007 08:59:57 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4czF-00075y-6n for pcn@ietf.org; Tue, 18 Dec 2007 08:59:57 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F2EF8211FD; Tue, 18 Dec 2007 14:59:38 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-9f-4767d24a94bc Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E228E2115A; Tue, 18 Dec 2007 14:59:38 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 14:59: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] Architecture draft- bi-directional flows Date: Tue, 18 Dec 2007 14:59:37 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC05067893EA@esealmw109.eemea.ericsson.se> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646513AA9A27@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft- bi-directional flows Thread-Index: Acg7PeyPVSOVh7W6Rc+UHvJYp4Jh5wFfoa0QAC6gVvA= References: <2782A678-5FE2-480F-9AB6-74A21885C8CB@cisco.com> <9671A92C3C8B5744BC97F855F7CB646513AA9A27@zcarhxm1.corp.nortel.com> From: "Ingemar Johansson S" To: "Jozef Babiarz" , "PCN IETF" X-OriginalArrivalTime: 18 Dec 2007 13:59:38.0703 (UTC) FILETIME=[3ABA45F0:01C8417E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 I would say that scenarios like this are covered atleast if SIP is used as protocol for the session setup as there are features in the protocol that handles the case that "crap hits the fan".=20 I would assume that simular mechanisms exist for other session setup protocols aswell. Here one can maybe pay some attention to how long it actually takes to be "admitted" as it may impact of session setup times. This would require a dialog between the PCN admission protocol and the session setup protocol but I beleieve that it is more a headache for the protocol that handles the resource reservation than PCN itself as this problem is not only related to PCN (similar issues/problem statements and solutions exist in 3GPP wireless access). Termination issue: I believe that this is handled aswell. As a last resort RTP contains a mechanism that ensures termination after a period of silence in one direction, SIP also contains mechanisms for (abnormal) teardown. Ingemar =20 > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 > Sent: den 17 december 2007 15:58 > To: PCN IETF > Subject: RE: [PCN] Architecture draft- bi-directional flows >=20 > In my additional review of the PCN Architecture draft, I=20 > realized that there is no mention of how bi-directional flows=20 > are handled. >=20 > I believe that the PCN Architecture draft needs to discuss=20 > and explain how admission control and flow termination works=20 > at high level for telephony and video conferencing=20 > applications and that both, telephony and video conferencing=20 > applications have bi-directional flows. For admission control=20 > a new flow can not be admitted unless the traffic level on=20 > both unidirectional paths is below the PCN-lower-rate. As=20 > well for flow termination, a bi-directional flow is=20 > terminated if one of the unidirectional paths is in excess of=20 > PCN-upper-rate.=20 >=20 >=20 > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 >=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 Wed Dec 19 10:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50uT-0002qg-Sa; Wed, 19 Dec 2007 10:32:37 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J50uS-0002qX-9B for pcn-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 10:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50uR-0002qP-Vm for pcn@ietf.org; Wed, 19 Dec 2007 10:32:35 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50uQ-0008WO-Bg for pcn@ietf.org; Wed, 19 Dec 2007 10:32:35 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 15:32:54 +0000 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, 19 Dec 2007 15:32:37 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B343FA@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN dinner consensus thread-index: Acg7PNAIuRw7pMFuSwGA6R7UgpFcVgHFq/AA From: To: X-OriginalArrivalTime: 19 Dec 2007 15:32:54.0551 (UTC) FILETIME=[6C86AA70:01C84254] X-Spam-Score: -1.0 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: bob.briscoe@bt.com Subject: [PCN] RE: PCN dinner consensus 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 PCN-ers, Several of us [cc'd] met over a couple of "corridor" meetings. We've agreed a way forward until Philadelphia in terms of where we're going to concentrate our particular efforts, in order to increase the chances of success on the Milestone '(Pre-)Congestion Detection within a DiffServ Domain' due March 2008. =20 Over the next few months, we will make the working assumption of the "CL marking behaviour" and explain/test this assumption (eg with further simulations): * "CL marking" means threshold-marking (step) for admission control & excess-rate-marking for flow termination.=20 * Single Marking - this is potentially a migration step to CL. Explain why SM is not enough (when is it enough?) * 3SM - we believe that the overall behaviour in the 3SM draft can be approximated with the CL marking + different edge behaviour. Explain how (and what is lost). We had a good session to understand the pros/cons of 3SM in more detail, and what simuls might help on this.=20 * LC-PCN - we believe that Affected Marking could in principle be added to CL (or indeed to SM). Assess whether the benefit is worth the cost (are any simulations possible?) =20 Results etc of course on list and perhaps as a Part B to http://tools.ietf.org/wg/pcn/draft-charny-pcn-comparison-00.txt - in order to help the decision what marking approach to standardise. =20 Note, this is just an unofficial understanding between some of us, in an effort to increase the chances of the WG making a decision around the next IETF (when the Milestone is due), and of course doesn't stop other proposals and work. Hopefully the above captures what we agree (cc'd people, please correct mistakes!). =20 Best wishes & have a nice Chistmas, Phil=20 =20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Dec 19 10:56: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 1J51HL-0006Pu-AG; Wed, 19 Dec 2007 10:56:15 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J51HK-0006Pj-6b for pcn-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 10:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51HJ-0006OF-Ss for pcn@ietf.org; Wed, 19 Dec 2007 10:56:13 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J51HH-0000VX-FP for pcn@ietf.org; Wed, 19 Dec 2007 10:56:13 -0500 Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lBJFu2bJ007387; Wed, 19 Dec 2007 16:56:09 +0100 (MET) From: "Georgios Karagiannis" To: , References: <75A199C5D243C741BF3D3F1EBCEF9BA503B343FA@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> Subject: RE: [PCN] RE: PCN dinner consensus Date: Wed, 19 Dec 2007 16:55:55 +0100 Message-ID: <000b01c84257$a913e360$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Acg7PNAIuRw7pMFuSwGA6R7UgpFcVgHFq/AAAAClp6A= X-Spam-Score: 0.1 () FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Dec 2007 16:56:09 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: bob.briscoe@bt.com 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, Hi all Thank you very much! Regarding LC-PCN: * it will be good to explain how the LC-PCN overall behaviour in PCN_iterior_nodes can be approximated using SM or CL + different edge behaviour. * Affected Marking, agree to be added to SM and CL * About probing, I think that it is usefull to investigate it, such that it could be used as an option for CL++ and SM++. I would very much like to wish to you and to your families: Merry Christmas and a Happy New Year Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 19 december 2007 16:33 > To: pcn@ietf.org > Cc: bob.briscoe@bt.com > Subject: [PCN] RE: PCN dinner consensus > > PCN-ers, > Several of us [cc'd] met over a couple of "corridor" > meetings. We've agreed a way forward until Philadelphia in > terms of where we're going to concentrate our particular > efforts, in order to increase the chances of success on the > Milestone '(Pre-)Congestion Detection within a DiffServ > Domain' due March 2008. > > Over the next few months, we will make the working assumption > of the "CL marking behaviour" and explain/test this > assumption (eg with further > simulations): > * "CL marking" means threshold-marking (step) for admission > control & excess-rate-marking for flow termination. > * Single Marking - this is potentially a migration step to > CL. Explain why SM is not enough (when is it enough?) > * 3SM - we believe that the overall behaviour in the 3SM > draft can be approximated with the CL marking + different > edge behaviour. Explain how (and what is lost). We had a good > session to understand the pros/cons of 3SM in more detail, > and what simuls might help on this. > * LC-PCN - we believe that Affected Marking could in > principle be added to CL (or indeed to SM). Assess whether > the benefit is worth the cost (are any simulations possible?) > > Results etc of course on list and perhaps as a Part B to > http://tools.ietf.org/wg/pcn/draft-charny-pcn-comparison-00.tx t - in order to help the decision what marking approach to > standardise. > > Note, this is just an unofficial understanding between some > of us, in an effort to increase the chances of the WG making > a decision around the next IETF (when the Milestone is due), > and of course doesn't stop other proposals and work. > Hopefully the above captures what we agree (cc'd people, > please correct mistakes!). > > Best wishes & have a nice Chistmas, > 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 Wed Dec 19 11:33: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 1J51r7-0001mV-Pj; Wed, 19 Dec 2007 11:33:13 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J51r5-0001mP-QA for pcn-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 11:33:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51r5-0001mH-FP for pcn@ietf.org; Wed, 19 Dec 2007 11:33:11 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J51r4-0006c8-Pu for pcn@ietf.org; Wed, 19 Dec 2007 11:33:11 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:33:31 +0000 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, 19 Dec 2007 16:33:30 +0000 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 1198081988542; Wed, 19 Dec 2007 16:33:08 +0000 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 lBJGWOeI021803; Wed, 19 Dec 2007 16:32:37 GMT Message-Id: <5.2.1.1.2.20071219163136.04515ed0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 19 Dec 2007 16:32:41 +0000 To: "Georgios Karagiannis" From: Bob Briscoe Subject: RE: [PCN] RE: PCN dinner consensus In-Reply-To: <000b01c84257$a913e360$810c5982@dynamic.ewi.utwente.nl> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B343FA@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> 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: 19 Dec 2007 16:33:30.0812 (UTC) FILETIME=[E3E80FC0:01C8425C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Georgios, At 15:55 19/12/2007, Georgios Karagiannis wrote: >* About probing, I think that it is usefull to investigate it, >such that it could be used as an >option for CL++ and SM++. In Vancouver there was a lot of discussion about how much the w-g will / won't discuss probing. See minutes posted by Steve Blake recently for the discussions. 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 Wed Dec 19 13:22: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 1J53YU-00058m-2b; Wed, 19 Dec 2007 13:22:06 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J53YS-00058L-25 for pcn-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:22:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53YR-00057z-EH for pcn@ietf.org; Wed, 19 Dec 2007 13:22:03 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J53YQ-0001N7-Nm for pcn@ietf.org; Wed, 19 Dec 2007 13:22:03 -0500 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 18:22:23 +0000 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: PCN dinner consensus Date: Wed, 19 Dec 2007 18:22:22 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34449@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000b01c84257$a913e360$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] RE: PCN dinner consensus thread-index: Acg7PNAIuRw7pMFuSwGA6R7UgpFcVgHFq/AAAAClp6AAAKTqcA== From: To: , X-OriginalArrivalTime: 19 Dec 2007 18:22:23.0155 (UTC) FILETIME=[197C8030:01C8426C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: bob.briscoe@bt.com 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: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 19 December 2007 15:56 > To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Cc: Briscoe,RJ,Bob,CXR9 R > Subject: RE: [PCN] RE: PCN dinner consensus >=20 > Hi Phil, Hi all >=20 > Thank you very much! >=20 > Regarding LC-PCN: > * it will be good to explain how the LC-PCN overall behaviour > in PCN_iterior_nodes can be approximated using SM or CL + different > edge behaviour. Sure! - Personally I don't understand lc-pcn well enough to be able to help with this.=20 > * Affected Marking, agree to be added to SM and CL it would be good if we could come up with any analysis /simulations to get a better handle of how much benefit it would offer in what circumstances. Any thoughts or work you've already done? That way we can judge better whether or not it should be added.=20 > * About probing, I think that it is usefull to investigate it, > such that it could be used as an > option for CL++ and SM++. Note the Chairs email about probing=20 >=20 > I would very much like to wish to you and to your families: >=20 > Merry Christmas and a Happy New Year >=20 and to you! phil > Best regards, > Georgios >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 19 december 2007 16:33 > > To: pcn@ietf.org > > Cc: bob.briscoe@bt.com > > Subject: [PCN] RE: PCN dinner consensus > > > > PCN-ers, > > Several of us [cc'd] met over a couple of "corridor" > > meetings. We've agreed a way forward until Philadelphia in > > terms of where we're going to concentrate our particular > > efforts, in order to increase the chances of success on the > > Milestone '(Pre-)Congestion Detection within a DiffServ > > Domain' due March 2008. > > > > Over the next few months, we will make the working assumption > > of the "CL marking behaviour" and explain/test this > > assumption (eg with further > > simulations): > > * "CL marking" means threshold-marking (step) for admission > > control & excess-rate-marking for flow termination. > > * Single Marking - this is potentially a migration step to > > CL. Explain why SM is not enough (when is it enough?) > > * 3SM - we believe that the overall behaviour in the 3SM > > draft can be approximated with the CL marking + different > > edge behaviour. Explain how (and what is lost). We had a good > > session to understand the pros/cons of 3SM in more detail, > > and what simuls might help on this. > > * LC-PCN - we believe that Affected Marking could in > > principle be added to CL (or indeed to SM). Assess whether > > the benefit is worth the cost (are any simulations possible?) > > > > Results etc of course on list and perhaps as a Part B to > > http://tools.ietf.org/wg/pcn/draft-charny-pcn-comparison-00.tx > t - in order to help the decision what marking approach to > standardise. > > > > Note, this is just an unofficial understanding between some > > of us, in an effort to increase the chances of the WG making > > a decision around the next IETF (when the Milestone is due), > > and of course doesn't stop other proposals and work. > > Hopefully the above captures what we agree (cc'd people, > > please correct mistakes!). > > > > Best wishes & have a nice Chistmas, > > Phil > > > > > > > > > > _______________________________________________ > > 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 Thu Dec 20 10:56: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 1J5NlM-0007Tp-TQ; Thu, 20 Dec 2007 10:56:44 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J5NlL-0007T6-Rh for pcn-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 10:56:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5NlL-0007Su-HL for pcn@ietf.org; Thu, 20 Dec 2007 10:56:43 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5NlK-0000op-VP for pcn@ietf.org; Thu, 20 Dec 2007 10:56:43 -0500 Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lBKFu8cF019001; Thu, 20 Dec 2007 16:56:31 +0100 (MET) From: "Georgios Karagiannis" To: "'Bob Briscoe'" References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B343FA@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> <5.2.1.1.2.20071219163136.04515ed0@pop3.jungle.bt.co.uk> Subject: RE: [PCN] RE: PCN dinner consensus Date: Thu, 20 Dec 2007 16:56:02 +0100 Message-ID: <003601c84320$e1443fe0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5.2.1.1.2.20071219163136.04515ed0@pop3.jungle.bt.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchCYX5nZR0jd0eJRhGW/ba//wpMYAAvt7mQ X-Spam-Score: 0.6 () J_CHICKENPOX_57 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 20 Dec 2007 16:56:31 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Bob Checking the minutes, the only things that I could find on probing were associated with the architecture draft. The architecture draft does not exclude the use of probing. Thus I do not see that probing is excluded from future PCN activities. Best regards, Georgios > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: woensdag 19 december 2007 17:33 > To: Georgios Karagiannis > Cc: philip.eardley@bt.com; pcn@ietf.org > Subject: RE: [PCN] RE: PCN dinner consensus > > Georgios, > > At 15:55 19/12/2007, Georgios Karagiannis wrote: > >* About probing, I think that it is usefull to investigate it, such > >that it could be used as an option for CL++ and SM++. > > In Vancouver there was a lot of discussion about how much the > w-g will / won't discuss probing. See minutes posted by Steve > Blake recently for the discussions. > > > 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 Dec 20 11:52: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 1J5Ocw-0005E0-Ij; Thu, 20 Dec 2007 11:52:06 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J5Ocu-0005DO-NZ for pcn-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 11:52:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Ocu-0005DE-CS for pcn@ietf.org; Thu, 20 Dec 2007 11:52:04 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Oct-00029o-Ua for pcn@ietf.org; Thu, 20 Dec 2007 11:52:04 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 16:52:25 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 16:52:25 +0000 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 119816952134; Thu, 20 Dec 2007 16:52:01 +0000 Received: from mut.jungle.bt.co.uk ([10.73.147.65]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id lBKGpViO014222; Thu, 20 Dec 2007 16:51:44 GMT Message-Id: <5.2.1.1.2.20071220164838.04556c28@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 20 Dec 2007 16:51:29 +0000 To: "Georgios Karagiannis" From: Bob Briscoe Subject: RE: [PCN] RE: PCN dinner consensus In-Reply-To: <003601c84320$e1443fe0$810c5982@dynamic.ewi.utwente.nl> References: <5.2.1.1.2.20071219163136.04515ed0@pop3.jungle.bt.co.uk> <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B343FA@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B34443@E03MVZ1-UKDY.domain1.systemhost.net> <5.2.1.1.2.20071219163136.04515ed0@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 Dec 2007 16:52:25.0215 (UTC) FILETIME=[B279F8F0:01C84328] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Georgios, Quoting straw poll in notes: >Steve: [...] How many think protocol work on probing should be done right >now? No one. > >Lars: how many think it should be done before arch draft WGLC? No one. But you're right, probing is not excluded from future activities, just current ones. Bob At 15:56 20/12/2007, Georgios Karagiannis wrote: >Hi Bob > >Checking the minutes, the only things that I could find on probing were >associated with the architecture draft. The architecture draft does not >exclude the use of probing. >Thus I do not see that probing is excluded from future PCN activities. > >Best regards, >Georgios > > > > > > > -----Original Message----- > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > Sent: woensdag 19 december 2007 17:33 > > To: Georgios Karagiannis > > Cc: philip.eardley@bt.com; pcn@ietf.org > > Subject: RE: [PCN] RE: PCN dinner consensus > > > > Georgios, > > > > At 15:55 19/12/2007, Georgios Karagiannis wrote: > > >* About probing, I think that it is usefull to investigate it, such > > >that it could be used as an option for CL++ and SM++. > > > > In Vancouver there was a lot of discussion about how much the > > w-g will / won't discuss probing. See minutes posted by Steve > > Blake recently for the discussions. > > > > > > Bob > > > > > > ______________________________________________________________ > > ______________ > > Bob Briscoe, Networks Research > > Centre, BT Research > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > +44 1473 645196 > > > > ____________________________________________________________________________ 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 Dec 20 22:39: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 1J5YjH-0000vJ-1D; Thu, 20 Dec 2007 22:39:19 -0500 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1J5YjF-0000vD-B3 for pcn-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 22:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5YjE-0000v5-LR for pcn@ietf.org; Thu, 20 Dec 2007 22:39:16 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5YjE-0003Fp-9h for pcn@ietf.org; Thu, 20 Dec 2007 22:39:16 -0500 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 lBL3dDJ25957; Fri, 21 Dec 2007 03:39:13 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] Questions on centralised control nodes Date: Thu, 20 Dec 2007 22:39:11 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB646513C4C5E5@zcarhxm1.corp.nortel.com> In-Reply-To: <1197403234.21366.47.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Questions on centralised control nodes Thread-Index: Acg8MI37xG9eJ8dpRX6WpMmCuQIQegHUgvgQ References: <1197403234.21366.47.camel@neutrino> From: "Jozef Babiarz" To: "Steven Blake" , "pcn" X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 1- Yes. 2- Yes. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Steven Blake [mailto:steven.blake@ericsson.com]=20 Sent: December 11, 2007 3:01 PM To: pcn Subject: [PCN] Questions on centralised control nodes During last week's meeting there was some discussion regarding the role of centralised control nodes in PCN (see the preliminary minutes): 1. Does there need to be any discussion of centralized decision nodes in the architecture draft? 2. If yes to (1), is the current text in the architecture draft sufficient? By the judgement of the chairs, the consensus of the room for each question was 1 - Yes, 2 - Yes. We are opening these questions for discussion on the list. Please review the architecture draft -02 and send your feedback to the list. Regards, 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn