From pcn-bounces@ietf.org Tue Apr 03 10:35:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYk6O-0000zy-9B; Tue, 03 Apr 2007 10:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYk6N-0000yM-3V for pcn@ietf.org; Tue, 03 Apr 2007 10:35:15 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYk26-0000ag-2L for pcn@ietf.org; Tue, 03 Apr 2007 10:30:55 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l33EuSkX020402 for ; Tue, 3 Apr 2007 09:56:28 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 09:30:47 -0500 Received: from [147.117.169.165] ([147.117.169.165]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 09:30:47 -0500 From: Steven Blake To: pcn Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 03 Apr 2007 10:30:46 -0400 Message-Id: <1175610646.11225.52.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2007 14:30:47.0224 (UTC) FILETIME=[AB76B380:01C775FC] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Subject: [PCN] Preliminary minutes from IETF 68 meeting 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 For those who attended the PCN meeting in Prague: Please review the preliminary meeting minutes below, and send comments/corrections to the list. Thanks to Dave Borman, Fred Baker, Anna Charny, and Spencer Dawkins for taking notes during the meeting, and thanks to Scott for editing them. ----------------------------------- Congestion & Pre-congestion Notification Working Group March 19, 2007 Meeting Minutes taken by Dave Borman, Fred Baker, Anna Charny and Spencer Dawkins Chairs - Scott Bradner & Steven Blake Pre-congestion notification working group 19 March 2007 o Administrivia Scott Bradner gave a brief discussion of the fact that pcn is now a working group and needs to work to its charter. An opportunity was given to bash the agenda, and no bashing occurred. o Charter review Steve Blake read the charter to the working group. Especially on restrictions. One diffserv domain with trusted members. Milestones are revised after consultation with ADs. A mix of Informational and Proposed Standard documents. Architecture document will be comprehensive, including security and OAM. Lots of "may consider after completing" items - concatenated diffserv domains, etc. Would recharter to work on these. Stuart Goldman pointed the group to a draft (draft-goldman-pcn) regarding PSTN interactions. The chairs suggested that this belonged on a non-working group list. Scott: you can have non-wg discussion on non-wg items on non-wg mailing lists. o PCN Flow Admission and Termination Architecture Kwok-Ho Chan (see slides) Kwok gave an overview of previous work by himself, Josef Babiarz, Bob Briscoe, and others. Scott noted that while this is prior work, it is not grandfathered as the approach the working group is to take. The working group needs to look at the various proposals and decide on an approach. The key concepts are given in the following documents: http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region", Bob Briscoe, 25-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06, http://tools.ietf.org/html/draft-chan-pcn-problem-statement "Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25-Oct-06, Architectural considerations came out while writing the problem statement that need to be considered in the architecture, including the distinction between functions of the data plane and functions of the end systems that interpret its results. Kwok commented that there was value in thinking this should be thought about in a trans-domain fashion. PCN architecture discussions talk about interior nodes and edge nodes. Interior nodes mark, edge nodes use marking for flow admission and termination decisions. Architecture and problem statements probably need to be merged. Have done some work on traffic measurement with simulation work. Done to provoke thought. Is the architecture the subset or the superset? Lars: The WG would focus on single diffserv domain. Need to get marking semantics right, will be difficult to change later. Can't change diffserv architecture, but can add to it. Tina Tsou - Will have general architecture as superset, right? Right. Bob Briscoe: is concerned about designing the architecture for a single domain. He would argue for designing for the Internet and figuring how to use it in a single domain. Lars: part of the issue is trust domains. We need to be able to design the mechanisms assuming that we are within a common trust domain first, and then figure out trans-domain. Bob Briscoe - thought we needed to look at multi-domain. Diffserv was multi-domain. Scott - focus was on what a router does, regardless of domain. Lars - if you have multi-domain, you have to talk about security story. IESG thought single domain was best understood. We can discuss when we see the single domain work. Scott - would be premature to work on multi-domain if you don't have single domain yet. You can publish an individual draft individual draft using "pcn" in the file name even if the topic was beyond the scope of the WG, although it would not be discussed in the working group. ?Woody?Govat? wants to know whether trans-domain work should go to the transport working group. Lars - not in TSVWG - too confusing to talk in two places at once. Bob Briscoe - the picture of PCN arch isn't the whole internet, just a (big) hop (conceptually an AS). Scott - there are a number of constructs on how the internet. E.g., a single ISP can have multiple domains. Our charter says one domain. We can say there are other scenarios and multi-domain situations, but leave it as that without going further. Scott: markings don't leak, but are interpreted by an edge box. Making a statement in the architecture document about leaking markers and trust between domains as issues can be stated, but we don't have to go into them. Bob: Assume when we get to multi-domain, we'll need a new architecture document: Question: what did we agree on? Scott: We agreed to follow the working group charter. Steven: we have an 18 month schedule. There'll be plenty of time to move onward after that. Kwok continued with a discussion of the duties of an interior node, which boil down to simply, scalably, and interoperably calculate throughput and congestion indicators and mark traffic accordingly. The edge node needs then to do the right thing with the aggregate of those marks, which may include dropping packets or triggering application behavior such as terminating sessions. Kwok noted that we need common terminology. A show of hands suggested that including a glossary in the architecture draft makes the most sense. Lars noted that using diffserv terminology where applicable would be wise. Anna Charny suggested that the people who may want to work on the terminology may not be the same people who will want to work on the architecture.. Lars - reuse diffserv terminology (please). Expecting impact on architecture from flow rate adaption, cheating detection, multi-domain, application control. Don't want Interior Nodes to change if we work on these items. Basically, the architecture and terminology are not complete until that issue is settled. Kwok also mentioned several non-goals need to be considered while designing the architecture. Lars noted that standards track outputs of this working group should not change when the matter goes trans-domain. This of course has implications - trans-domain needs to be thought about enough to prevent such rework. Joe Evers asked whether it would be appropriate to have individual submissions for various parts of the non-goal discussions. Scott indicated that doing non-goal work tends to disrupt the progress of the working group. Bob Briscoe, commented that the scoping issue may make it difficult to produce a stable transdomain solution in a single-domain effort. Kwok also discussed a survey of encoding. He indicated that the DSCP could be used if PHBs are reworked to allow for additional coding. Chris Christou noted the Hiccup BOF, where the applicability to emergency communications may be discussed. Tina Tsou asked whether the measurements occurred on aggregates between ingress/egress pairs. Kwok - diffserv traffic aggregates within a single diffserv domain are under consideration here. Scott suggested that the best way to compare marking strategies was multiple drafts by the proponents. Josef Babiarz indicated that it would be better in a common draft. Dave McDysan suggested that measures of comparison including performance would be good to include in the performance metrics. Need to agree on methods of comparison of different need to agree on criteria for comparison of different approaches. He suggested compiling a common draft from several separate drafts. Scott: idea of comparison criteria is useful; need to develop that o Performance Evaluation of CL-PHB Admission and pre-emption Algorithms Joy Zhang Joy discussed simulation experiments the authors have been doing to validate the architecture. They simulated CBR, on/off voice, synthetic video, and a real video trace. Her previously reported admission observations were that when correctly configured the algorithm worked well on links that had a high ratio of capacity to individual session size. Dave McDysan commented that the results should have some measure of the real effect. Anna Charny indicated that the testing Joy was reporting showed over-admission percentage rather than over-preemption. It is a milder statement than the above. Preemption/Termination observations were that over-preemption was possible, especially in a long RTT channel, since it depends on the probable view as seen by differing systems. If all edge devices preempt at the same ECN-CE density and all flows in an aggregate are marked with the same probability, one would expect all sessions to drop simultaneously with some probability when only a few need to. With multiple bottlenecks, a situation an occur in which one bottleneck can see variation in load when a second bottleneck builds on its marks to mark traffic. She noted that in her simulations this was not as much of a problem as expected. Georgios Karagiannis - Have you looked into marked/unmarked packets are lost? Joy: No. Simulations assume all packets get through: Anna Charney: Only assume that some of the marked packets get through. Argenous ? wanted to know how many sources one needed to make PCN work. Joy said that estimates of such were in her draft. ???: How does a PCN enabled router mark with different RTTs? Steve: In the charter, we only assume inelastic flows. Anna Charney: Differences in RTT didn't have much of an effect o Pre-Congestion Notification Using Single Marking for Admission and Pre-emption Anna Charny Have written overview that follows PCN drafts closely. Want to talk about tradeoffs and next steps. Core just does marking, egress measures unmarked traffic. Works like preemption in CL drafts except that there's only one marking. Ingress computes sustainable flow termination rate. Good - save one codepoint (important with MPLS), one metering measurement. Bad - not sure how to change K parameter system-wide, excess-rate admission control is more sensitive to parameters and traffic patterns, conflicts with Bob Briscoe anti-cheating mechanism. Does WG need to choose between two (or more) mechanisms, or is there a way to include them all in the standard? May be able to define single-marking as a subset of two-threshold marking behavior. If only some core devices support type 1 and type 2, must all revert to type 1 and be configured with the same K constant. Single-marking appears technically viable - fewer implementation changes to existing core equipment, smaller performance impact in data path of core routers. Have you looked a ECMP with multihopping? Only choose flows that have been marked. Not sure if we can just ignore this - don't do anything. This is an open question. There is a problem even with per-flow load balancing across multiple paths. Looked at aggregates with different numbers of flows? Not yet, don't see why it would change, want to understand why you think this is a problem. When everyone has a small number of flows, that's probably worst-case. On-off patterns are already included in simulations. Does anyone see any major holes? Joe Babiarz - How with multi-path routing? Anna: When you preempt, can we just not do anything? You might pick the wrong one, but hopefully over time it will work Scott: if you hash the high order bits in route selection, is there a problem? Joe: yes - The assumption is that one route is congested, and the other isn't. Joe: Have you considered a disparity in the number of flows? Anna: doesn't matter much. Worst case is when everyone has a small number of flows. Joe: When you have on-off traffic, is during your measurements? Say 40/60, how do you address the error when the 40 percent isn't sending? Anna: We don't address that error. Bob: Are you saying it's easier to use a token bucket for this? Anna: the marking here is the same as it is today. The token marking of the virtual queue will require more work. Jozef Babiarz: #flows is calculated at ingress. Another way is to calculate at egress. Is that a difference? Anna: it doesn't change things for these measurements, but it can be looked at. Anna: should the WG consider allowing two or more options? Or should there be just one? Steve: There are tradeoffs, and performance is not the only one, or even the most important one. Implementation is important. Scott: IPR consideration is another item. The Cisco IPR statement is fine, it's been accepted in some WGs, and rejected in others. Lars: One reason that the encoding is a proposed standard is for interoperability. If you have multiple versions, you fragment the solution space. The initial hope was for one solution that is good enough for most situations. Unclear if this is a clever renaming or if there is a conflict. o Explicit PCN Marking Jozef Babiarz This is only for flow termination, not admission control. Want to stay above Admissible rate, but below Supportable rate. Mark packets above supportable rate. The charts have two situations. One, fast failover, second slowly transition traffic. Egress routers monitor packets, signal what flows are marked to ingress routers. Have done simulation for voice, video, etc. Preemption does work, but really bursty traffic needs a large token bucket. Termination happens when preemption doesn't happen. This is a different tradeoff than previous presentation - react quickly, or avoid over-preemption. WG needs to discuss what we want to happen. As part of definition, need to decide how fast we need to converge. Before people timeout and hang up - that's too late. RTT doesn't matter - do different RTTs in the same network matter? Expect parameters would be selected based on longest RTT in the system. Bob Briscoe: Preemption or flow termination is a last resort when other things haven't worked. Joy was describing a situation to preempt as fast as possible, Joe's is to do preemption slower. ???: Joe commented several times it works well, it is personal preference on what "works well" means. How fast do you need things to converge? If people hang up before things converge, that's a problem. Scott: you need to think about the human reaction time, not just the system reaction time. If the human time is faster, that's not good. Joe: simulated different RTTs, and reaction time was different for each value. Anna: does it matter when you have different RTTs in the same network? Joe: we haven't tested that. Lars: The point is to alleviate congestion quickly. It would be useful to stick to that. Scott: The term "quickly" is not easily defined. o Next Steps for WG... Scott: How do we move forward? The authors that are up already, should make sure the documents are concurrent with the charter. If you think it is consistent with the charter, then send it to the chairs and the mailing list will be used to get consensus. Volunteers are wanted for the documents on the to-do list. Chris ???: BOF is at 11:50 AM in Congress I. ----------------------------------- Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson Data Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 03 15:21: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 1HYoZO-0007w2-5T; Tue, 03 Apr 2007 15:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoZN-0007vx-G5 for pcn@ietf.org; Tue, 03 Apr 2007 15:21:29 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYoZL-0004uT-9L for pcn@ietf.org; Tue, 03 Apr 2007 15:21:29 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l33JLOb09812; Tue, 3 Apr 2007 19:21:25 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] Preliminary minutes from IETF 68 meeting Date: Tue, 3 Apr 2007 15:21:07 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650F887153@zcarhxm1.corp.nortel.com> In-Reply-To: <1175610646.11225.52.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Preliminary minutes from IETF 68 meeting Thread-Index: Acd1/XKNmaefNZ9+TBCDORD9Uwa4zQAJwClw From: "Jozef Babiarz" To: "Steven Blake" , "pcn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d53b06eede2bb6b618e318c7466f38f 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 Steven some minor changes and comments on >o Explicit PCN Marking >Jozef Babiarz > =20 > >This is only for flow termination, not admission control. > >Want to stay above Admissible rate, but below Supportable rate. > >Mark packets above supportable rate. > >The charts have two situations. One, fast failover, second slowly >transition traffic. > I believe I said: The simulation results show two failure situations. First shown on graph is fast failover and second under slower transition of failover traffic, 80% within one second and remain 20% within 5 seconds. >Egress routers monitor packets, signal what flows are marked to >ingress routers. > I believe I said: Interior routers mark packets, egress routers monitor for packet marking, signal what flows are marked to ingress routers and ingress routers execute flow termination procedure.=20 =20 >Have done simulation for voice, video, etc. Preemption does work, but >really bursty traffic needs a large token bucket. > >Termination happens when preemption doesn't happen. This is a >different tradeoff than previous presentation - react quickly, or >avoid over-preemption. WG needs to discuss what we want to happen. > Explanation of the above issue, I think: Flow termination response for Explicit marking is proportional to the level of overload or congestion. Flow termination is fast (RTT after marking) and aggressive (a flow every "x" bytes of excess traffic) under high overload condition and it slows down as it approaches supportable traffic level. The flow marking, and therefore termination process has exponential decay property. The other method (excess rate marking) works in the flowing way, egress routers measures over some time interval the rate of on-market traffic received per ingress-egress aggregate and signals to ingress router the rate that can be supported. On reception of the message, the ingress router performs a measurement over some time interval of the current offered traffic level for the ingress-egress aggregate and computes the amount of traffic and what flows need to be termination to bring the traffic level to supportable rate for the ingress-egress aggregate. Finally, the ingress router invokes the flow termination procedure.=20 The Explicit marking approach is different to the previous presented approach. The WG needs to discuss what we want to happen - react very quickly, or react to avoid over flow termination?=20 >As part of definition, need to decide how fast we need to converge. >Before people timeout and hang up - that's too late. > Joe's comment: During over load, having people voluntarily hang up maybe good, versus network forcing flow termination. However, the issue is how quickly the network returns to stable operation providing good service to remaining users. =20 >RTT doesn't matter - do different RTTs in the same network matter? >Expect parameters would be selected based on longest RTT in the >system. > The answer is: Not, if parameters are selected based on longest RTT. >Bob Briscoe: Preemption or flow termination is a last resort when >other things haven't worked. Joy was describing a situation to >preempt as fast as possible, Joe's is to do preemption slower. > >???: Joe commented several times it works well, it is personal >preference on what "works well" means. How fast do you need things to >converge? If people hang up before things converge, that's a problem. > >Scott: you need to think about the human reaction time, not just the >system reaction time. If the human time is faster, that's not good. > >Joe: simulated different RTTs, and reaction time was different for >each value. > Simulate different RTTs (2ms to 800ms), and reaction times are different. Results presented showed for RTT of 50ms flow termination took less than one second to bring load down to supportable rate.=20 >Anna: does it matter when you have different RTTs in the same network? > >Joe: we haven't tested that. > >Lars: The point is to alleviate congestion quickly. It would be >useful to stick to that. > >Scott: The term "quickly" is not easily defined. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Steven Blake [mailto:steven.blake@ericsson.com]=20 Sent: April 3, 2007 10:31 AM To: pcn Subject: [PCN] Preliminary minutes from IETF 68 meeting For those who attended the PCN meeting in Prague: Please review the preliminary meeting minutes below, and send comments/corrections to the list. Thanks to Dave Borman, Fred Baker, Anna Charny, and Spencer Dawkins for taking notes during the meeting, and thanks to Scott for editing them. ----------------------------------- Congestion & Pre-congestion Notification Working Group March 19, 2007 Meeting Minutes taken by Dave Borman, Fred Baker, Anna Charny and Spencer Dawkins Chairs - Scott Bradner & Steven Blake Pre-congestion notification working group 19 March 2007 o Administrivia Scott Bradner gave a brief discussion of the fact that pcn is now a working group and needs to work to its charter.=20 An opportunity was given to bash the agenda, and no bashing occurred. =20 =20 o Charter review Steve Blake read the charter to the working group. Especially on restrictions. One diffserv domain with trusted members. Milestones are revised after consultation with ADs. A mix of Informational and Proposed Standard documents. Architecture document will be comprehensive, including security and OAM. Lots of "may consider after completing" items - concatenated diffserv domains, etc. Would recharter to work on these. Stuart Goldman pointed the group to a draft (draft-goldman-pcn) regarding PSTN interactions. The chairs suggested that this belonged on a non-working group list. =20 Scott: you can have non-wg discussion on non-wg items on non-wg mailing lists. =20 =20 o PCN Flow Admission and Termination Architecture =20 Kwok-Ho Chan (see slides) Kwok gave an overview of previous work by himself, Josef Babiarz, Bob Briscoe, and others.=20 Scott noted that while this is prior work, it is not grandfathered as the approach the working group is to take.=20 The working group needs to look at the various proposals and decide on an approach. The key concepts are given in the following documents: http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region", Bob Briscoe, 25-Oct-06,=20 =20 http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06,=20 =20 http://tools.ietf.org/html/draft-chan-pcn-problem-statement "Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25-Oct-06,=20 =20 Architectural considerations came out while writing the problem statement that need to be considered in the architecture, including the distinction between functions of the data plane and functions of the end systems that interpret its results. Kwok commented that there was value in thinking this should be thought about in a trans-domain fashion. PCN architecture discussions talk about interior nodes and edge nodes. Interior nodes mark, edge nodes use marking for flow admission and termination decisions. Architecture and problem statements probably need to be merged. Have done some work on traffic measurement with simulation work. Done to provoke thought. Is the architecture the subset or the superset? Lars: The WG would focus on single diffserv domain. Need to get marking semantics right, will be difficult to change later. Can't change diffserv architecture, but can add to it. Tina Tsou - Will have general architecture as superset, right? Right. Bob Briscoe: is concerned about designing the architecture for a single domain. He would argue for designing for the=20 Internet and figuring how to use it in a single domain. Lars: part of the issue is trust domains. We need to be able to design the mechanisms assuming that we are within a=20 common trust domain first, and then figure out trans-domain. Bob Briscoe - thought we needed to look at multi-domain. Diffserv was multi-domain. Scott - focus was on what a router does, regardless of domain. Lars - if you have multi-domain, you have to talk about security story. IESG thought single domain was best understood. We can discuss when we see the single domain work. Scott - would be premature to work on multi-domain if you don't have single domain yet. You can publish an individual draft individual draft using "pcn" in the file name even if the topic was beyond the scope of the WG, although it would not be discussed in the working group. ?Woody?Govat? wants to know whether trans-domain work should go to the transport working group.=20 Lars - not in TSVWG - too confusing to talk in two places at once. Bob Briscoe - the picture of PCN arch isn't the whole internet, just a (big) hop (conceptually an AS). Scott - there are a number of constructs on how the internet. E.g., a single ISP can have multiple domains. Our charter says one domain. We can say there are other scenarios and multi-domain situations, but leave it as that without going further. Scott: markings don't leak, but are interpreted by an edge box. Making a statement in the architecture document about leaking markers and trust between domains as issues can be stated, but we don't have to go into them. Bob: Assume when we get to multi-domain, we'll need a new architecture document: Question: what did we agree on? Scott: We agreed to follow the working group charter. Steven: we have an 18 month schedule. There'll be plenty of time to move onward after that. Kwok continued with a discussion of the duties of an interior node, which boil down to simply, scalably,=20 and interoperably calculate throughput and congestion indicators and mark traffic accordingly.=20 The edge node needs then to do the right thing with the aggregate of those marks, which may include dropping=20 packets or triggering application behavior such as terminating sessions. Kwok noted that we need common terminology. A show of hands suggested that including a glossary in the architecture draft makes the most sense. Lars noted that using diffserv terminology where applicable would be wise. Anna Charny suggested that the people who may want to work on the terminology may not be the same people who will want to work on the architecture..=20 Lars - reuse diffserv terminology (please). Expecting impact on architecture from flow rate adaption, cheating detection, multi-domain, application control. Don't want Interior Nodes to change if we work on these items. Basically, the architecture and terminology are not complete until that issue is settled. Kwok also mentioned several non-goals need to be considered while designing the architecture. Lars noted that standards track outputs of this working group should not change when the matter goes trans-domain.=20 This of course has implications - trans-domain needs to be thought about enough to prevent such rework. Joe Evers asked whether it would be appropriate to have individual submissions for various parts of the non-goal discussions. Scott indicated that doing non-goal work tends to disrupt the progress of the working group. Bob Briscoe, commented that the scoping issue may make it difficult to produce a stable transdomain solution in a single-domain effort. Kwok also discussed a survey of encoding. He indicated that the DSCP could be used if PHBs are reworked to allow for additional coding. Chris Christou noted the Hiccup BOF, where the applicability to emergency communications may be discussed. Tina Tsou asked whether the measurements occurred on aggregates between ingress/egress pairs.=20 Kwok - diffserv traffic aggregates within a single diffserv domain are under consideration here. Scott suggested that the best way to compare marking strategies was multiple drafts by the proponents. =20 Josef Babiarz indicated that it would be better in a common draft.=20 Dave McDysan suggested that measures of comparison including performance would be good to include in the performance metrics. Need to agree on methods of comparison of different need to agree on criteria for comparison of different approaches. He suggested compiling a common draft from several separate drafts. Scott: idea of comparison criteria is useful; need to develop that =20 o Performance Evaluation of CL-PHB Admission and pre-emption Algorithms =20 Joy Zhang=20 =20 Joy discussed simulation experiments the authors have been doing to validate the architecture. They simulated CBR, on/off voice, synthetic video, and a real video trace.=20 Her previously reported admission observations were that when correctly configured the algorithm worked well on links that had a high ratio of capacity to individual session size. Dave McDysan commented that the results should have some measure of the real effect. Anna Charny indicated that the testing Joy was reporting showed over-admission percentage rather than over-preemption. It is a milder statement than the above. Preemption/Termination observations were that over-preemption was possible, especially in a long RTT channel, since it depends on the probable view as seen by differing systems. If all edge devices preempt at the same ECN-CE density and all flows in an aggregate are marked with the same probability, one would expect all sessions to drop simultaneously with some probability when only a few need to.=20 With multiple bottlenecks, a situation an occur in which one bottleneck can see variation in load when a second bottleneck builds on its marks to mark traffic. She noted that in her simulations this was not as much of a problem as expected. Georgios Karagiannis - Have you looked into marked/unmarked packets are lost? Joy: No. Simulations assume all packets get through: Anna Charney: Only assume that some of the marked packets get through. Argenous ? wanted to know how many sources one needed to make PCN work. Joy said that estimates of such were in her draft. ???: How does a PCN enabled router mark with different RTTs? Steve: In the charter, we only assume inelastic flows. Anna Charney: Differences in RTT didn't have much of an effect o Pre-Congestion Notification Using Single Marking for Admission and Pre-emption =20 Anna Charny =20 =20 Have written overview that follows PCN drafts closely. Want to talk about=20 tradeoffs and next steps. Core just does marking, egress measures unmarked traffic. Works like preemption in CL drafts except that there's only one marking. Ingress computes sustainable flow termination rate. Good - save one codepoint (important with MPLS), one metering measurement. Bad - not sure how to change K parameter system-wide, excess-rate admission control is more sensitive to parameters and traffic patterns, conflicts with Bob Briscoe anti-cheating mechanism. Does WG need to choose between two (or more) mechanisms, or is there a way to include them all in the standard? May be able to define single-marking as a subset of two-threshold marking behavior. If only some core devices support type 1 and type 2, must all revert to type 1 and be configured with the same K constant. Single-marking appears technically viable - fewer implementation changes to existing core equipment, smaller performance impact in data path of core routers. Have you looked a ECMP with multihopping? Only choose flows that have been marked. Not sure if we can just ignore this - don't do anything. This is an open question. There is a problem even with per-flow load balancing across multiple paths. Looked at aggregates with different numbers of flows? Not yet, don't see why it would change, want to understand why you think this is a problem. When everyone has a small number of flows, that's probably worst-case. On-off patterns are already included in simulations. Does anyone see any major holes? Joe Babiarz - How with multi-path routing? Anna: When you preempt, can we just not do anything? You might pick the wrong one, but hopefully over time it will work Scott: if you hash the high order bits in route selection, is there a problem? Joe: yes - The assumption is that one route is congested, and the other isn't. Joe: Have you considered a disparity in the number of flows? Anna: doesn't matter much. Worst case is when everyone has a small number of flows. Joe: When you have on-off traffic, is during your measurements? Say 40/60, how do you address the error when the 40 percent isn't sending? Anna: We don't address that error. Bob: Are you saying it's easier to use a token bucket for this? Anna: the marking here is the same as it is today. The token marking of the virtual queue will require more work. Jozef Babiarz: #flows is calculated at ingress. Another way is to calculate at egress. Is that a difference? Anna: it doesn't change things for these measurements, but it can be looked at. Anna: should the WG consider allowing two or more options? Or should there be just one? Steve: There are tradeoffs, and performance is not the only one, or even the most important one. Implementation is important. Scott: IPR consideration is another item. The Cisco IPR statement is fine, it's been accepted in some WGs, and rejected in others. Lars: One reason that the encoding is a proposed standard is for interoperability. If you have multiple versions, you fragment the solution space. The initial hope was for one solution that is good enough for most situations. Unclear if this is a clever renaming or if there is a conflict. o Explicit PCN Marking Jozef Babiarz =20 This is only for flow termination, not admission control. Want to stay above Admissible rate, but below Supportable rate. Mark packets above supportable rate. The charts have two situations. One, fast failover, second slowly transition traffic. Egress routers monitor packets, signal what flows are marked to ingress routers. Have done simulation for voice, video, etc. Preemption does work, but really bursty traffic needs a large token bucket. Termination happens when preemption doesn't happen. This is a different tradeoff than previous presentation - react quickly, or avoid over-preemption. WG needs to discuss what we want to happen. As part of definition, need to decide how fast we need to converge. Before people timeout and hang up - that's too late. RTT doesn't matter - do different RTTs in the same network matter? Expect parameters would be selected based on longest RTT in the system. Bob Briscoe: Preemption or flow termination is a last resort when other things haven't worked. Joy was describing a situation to preempt as fast as possible, Joe's is to do preemption slower. ???: Joe commented several times it works well, it is personal preference on what "works well" means. How fast do you need things to converge? If people hang up before things converge, that's a problem. Scott: you need to think about the human reaction time, not just the system reaction time. If the human time is faster, that's not good. Joe: simulated different RTTs, and reaction time was different for each value. Anna: does it matter when you have different RTTs in the same network? Joe: we haven't tested that. Lars: The point is to alleviate congestion quickly. It would be useful to stick to that. Scott: The term "quickly" is not easily defined. o Next Steps for WG... Scott: How do we move forward? The authors that are up already, should make sure the documents are concurrent with the charter. If you think it is consistent with the charter, then send it to the chairs and the mailing list will be used to get consensus. Volunteers are wanted for the documents on the to-do list. Chris ???: BOF is at 11:50 AM in Congress I. ----------------------------------- Regards, =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Steven Blake Ericsson Data 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 Apr 04 09:04: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 1HZ5AS-0000eM-V1; Wed, 04 Apr 2007 09:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ5AR-0000eE-SS for pcn@ietf.org; Wed, 04 Apr 2007 09:04:51 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ5AQ-00039e-5z for pcn@ietf.org; Wed, 04 Apr 2007 09:04:51 -0400 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 l34D4eQh015908; Wed, 4 Apr 2007 15:04:46 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kwok-Ho Chan'" , References: Subject: RE: [PCN] Kwok's notes for Thur 03/22/07 Mtg on PCN WG Initial WorkItems Date: Wed, 4 Apr 2007 15:04:34 +0200 Message-ID: <001801c776b9$ce246ef0$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.3028 In-Reply-To: Thread-Index: AcdyK/c1NxYc7vXkSMukM7QyiUB4iQEjWaDA X-Spam-Score: 0.09 () 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, 04 Apr 2007 15:04:47 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 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 Kwok A quick comment. Please note that I have volunteered to also work on "Flow Admission and Termination Architecture within a Diffserv Domain". Best Regards, Georgios > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: donderdag 29 maart 2007 19:59 > To: pcn@ietf.org > Subject: [PCN] Kwok's notes for Thur 03/22/07 Mtg on PCN WG > Initial WorkItems > > Hi all: > We held the meeting mentioned (attached original E-Mail) on > Thur March 22, 2007 16:30 (Prague time). > > We had a fruitful meeting. > Please see my meeting notes below for details. > > Please correct/add-to/delete-from the meeting notes as I may > have mis-interpreted, missed some points discussed during our meeting. > > Attendees: please check your names+e-mail, I may have made > mistakes reading your writing on the attendees sheet. > > We welcome additional volunteers who want to add their name > to the volunteers list. > Thanks! > -- Kwok -- > > > Kwok's Notes on the PCN Work Item Meeting on Thur March 22, > 2007 @ Prague > > Attendees: > Kwok Ho Chan (khchan@nortel.com), > Tina Tsou (tena@huawei.com), > Ken Young (keny@gridpointsystems.com), > Etsushi Ohyama (ohyama@ntt-at.ac.jp) > Michael Scharf (michael.scharf@ihr.uni-stuttgart.de), > Joe Babiarz (babiarz@nortel.com) > Shoichi Senda (s.senda@ntt-at.co.jp), > Ruediger Geib (ruediger.geib@t-systems.com) > Michael Menth (menth@informatik.uni-wuerzburg.de) (not present but > wanted to help) > Georgios Karagiannis (karagian@cs.utwente.nl), > Philip Eardley (philip.eardley@bt.com) > Anna Charny (acharny@cisco.com), > Bob Briscoe (bob.briscoe@bt.com) > Lars Eggert (lars.eggert@nokia.com) (attended the first half) > > > Meeting Notes: > We held this quick meeting for doing a start of the initial > PCN WG work items: > 1. "Flow Admission and Termination Architecture within a > Diffserv Domain", > Informational RFC, Nov 2007. > 2. "Survey of Encoding and Transport Choices of > (Pre-)Congestion Information > within a DiffServ Domain", Informational RFC, Nov 2007. > 3. "(Pre-)Congestion Detection within a DiffServ Domain", Proposed > Standard RFC, > Mar 2008. > > > Discussion Results: List of volunteers interested to work on this draft: > Kwok Ho Chan, Tina Tsou, Ken Young, Joe Babiarz, Ruediger Geib, > Micheal Menth, > Philip Eardley, Anna Charny > > For "Flow Admission and Termination Architecture within a > Diffserv Domain": > - We want this document to be at a high level, somewhere > between the current > Problem Statement draft and the CL Arch draft. > - > - Action Items: > 1. Philip Eardley to take architectural sections from the current > CL-Arch draft and Problem > Statement draft to create the first cut of the new WG work > item #1. This is to be at > a high level and should avoid the specific deployment model > from the CL-Arch draft. > 2. Kwok Ho Chan to create the initial Terminology Section for the > WG work item #1. > During our meeting, we determined we should try to have the > terminology be part of > the Architecture document to start, and move it to another > draft later if we need to. > We should try to keep the terminology section short and try to > reuse previously defined > terms whenever possible. > 3. The above action items should be completed in April 2007. All > volunteers for WG work > item #1 (and others) should review/comment/add-to the > first cut version. > - Goal: We should have the second version (-01) ready for WG review > before Chicago (69th) IETF. > > > For "Survey of Encoding and Transport Choices of (Pre-)Congestion > Information within a DiffServ Domain": > - Need to have the Chairs clarify the meaning of "Transport Choices" > for this WG work item. > May want to start by having a discussion of this on the WG list. > - Need to work closely with Sally Floyd on this. Need to use Sally's > RFC on this topic as guidance. > - List of volunteers interested to work on this draft: > Kwok Ho Chan, Joe Babiarz, Georgios Karagiannis, Anna Charny > - Action Items: > 1. Georgios Karagiannis to take the Appendix C of current CL-PHB > draft and create the > first cut of the new WG work item #2. > 2. All volunteers for WG work item #2 (and others) should > review/comment/add-to the > first cut version. > - Goal: We should at least have the first version (-00) ready for WG > review before Chicago (69th) IETF. > > > For "(Pre-)Congestion Detection within a DiffServ Domain": > - We agreed this work item milestone is the hardest one to > meet because of the > technical complexity and detail work required to execute this work > item correctly. > - During our discussion, we have identified that we may need another > draft (a new > WG Work Item) for the successful execution of this work item. > A draft on Criteria for Comparison of the different methods of > "(Pre-)Congestion Detection". > - Joe Babiarz indicated there is a (Pre)Congestion Admission Control > Detection draft > (companion to the Explicit Marking (for Flow > Termination/Pre-emption) draft) coming. > - Need to indicate/include dependencies between Detection and > Encoding. > - Action Items: > 1. Anna Charny to create the first cut of the "Criteria for > Comparing Detection Methods" draft. > Each methods' authors will provide Anna with list of criteria > each thinks is needed. > I think someone called this the "beauty contest rules" > draft. :) > Goal: Have at least the first version (-00) of this new draft > ready before the Chicago (69th) IETF. > 2. All "(Pre-)Congestion Detection Method" authors should continue > to improve on their individual > drafts. > 3. Geogios Karagiannis, Shoichi Senda, and others may want to > consider adding other > Detection Method drafts. > - Goal: Get the process started early for this difficult milestone. > > End of Kwok's Notes on the PCN Work Item Meeting on Thur March 22, > 2007 @ Prague. > > > At 12:18 AM 3/21/2007, Kwok-Ho Chan wrote: > >Hi all: > >Since the Monday PCN WG session at Prague IETF, couple of people > >have approached me informally on the hall way, during breaks, etc, > >indicated they would like to help in the PCN work items. > > > >I have talked to Steven (but did not get a chance to talk to > Scott yet) > >on holding a quick meeting while most of us are at Prague, > >to get the work on the first couple of PCN WG work items started. > >Steven have given his support on this. > > > >Hence how about a quick meeting: > >When: Wed March 21, 2007 16:30 (20 minutes into the cookie break) > >Where: IETF Registration Desk > > > >This will give us half an hour to talk before Plenary starts. > >Notice we may overflow into the Plenary if necessary. > > > >The topic will be to get a good sense on who wants to do what and > >how we may divide and focus on the different pieces. > > > >For people who can not attend, please send mail to the PCN list, > >Chairs, or myself > >if you choose to, on your interest and what, how you may > want to help. > > > >Thank you for all the energy and interest and hope to see you at the > >quick meeting > >indicated above. > >-- Kwok -- > > > > > > > > > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www1.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Apr 04 10:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6wa-0000wd-4W; Wed, 04 Apr 2007 10:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6wU-0000k7-OQ for pcn@ietf.org; Wed, 04 Apr 2007 10:58:34 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6ig-000611-My for pcn@ietf.org; Wed, 04 Apr 2007 10:44:20 -0400 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 l34Ei4v01315; Wed, 4 Apr 2007 14:44:04 GMT Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:43:51 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Apr 2007 10:43:50 -0400 To: "Georgios Karagiannis" From: "Kwok-Ho Chan" Subject: RE: [PCN] Kwok's notes for Thur 03/22/07 Mtg on PCN WG Initial WorkItems In-Reply-To: <001801c776b9$ce246ef0$4c0d5982@dynamic.ewi.utwente.nl> References: <001801c776b9$ce246ef0$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Apr 2007 14:43:51.0563 (UTC) FILETIME=[A96115B0:01C776C7] X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 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: Sorry that I have missed it in my notes. Please accept my apology. As I was trying to listen, think, take notes, and maybe talk simultaneously (some modes of time-slice :). I will correct it. Thanks! -- Kwok -- At 09:04 AM 4/4/2007, Georgios Karagiannis wrote: >Hi Kwok > >A quick comment. Please note that I have volunteered to also work on >"Flow Admission and Termination Architecture within a >Diffserv Domain". > >Best Regards, >Georgios > > > > -----Original Message----- > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > Sent: donderdag 29 maart 2007 19:59 > > To: pcn@ietf.org > > Subject: [PCN] Kwok's notes for Thur 03/22/07 Mtg on PCN WG > > Initial WorkItems > > > > Hi all: > > We held the meeting mentioned (attached original E-Mail) on > > Thur March 22, 2007 16:30 (Prague time). > > > > We had a fruitful meeting. > > Please see my meeting notes below for details. > > > > Please correct/add-to/delete-from the meeting notes as I may > > have mis-interpreted, missed some points discussed during our meeting. > > > > Attendees: please check your names+e-mail, I may have made > > mistakes reading your writing on the attendees sheet. > > > > We welcome additional volunteers who want to add their name > > to the volunteers list. > > Thanks! > > -- Kwok -- > > > > > > Kwok's Notes on the PCN Work Item Meeting on Thur March 22, > > 2007 @ Prague > > > > Attendees: > > Kwok Ho Chan (khchan@nortel.com), > > Tina Tsou (tena@huawei.com), > > Ken Young (keny@gridpointsystems.com), > > Etsushi Ohyama (ohyama@ntt-at.ac.jp) > > Michael Scharf (michael.scharf@ihr.uni-stuttgart.de), > > Joe Babiarz (babiarz@nortel.com) > > Shoichi Senda (s.senda@ntt-at.co.jp), > > Ruediger Geib (ruediger.geib@t-systems.com) > > Michael Menth (menth@informatik.uni-wuerzburg.de) (not present but > > wanted to help) > > Georgios Karagiannis (karagian@cs.utwente.nl), > > Philip Eardley (philip.eardley@bt.com) > > Anna Charny (acharny@cisco.com), > > Bob Briscoe (bob.briscoe@bt.com) > > Lars Eggert (lars.eggert@nokia.com) (attended the first half) > > > > > > Meeting Notes: > > We held this quick meeting for doing a start of the initial > > PCN WG work items: > > 1. "Flow Admission and Termination Architecture within a > > Diffserv Domain", > > Informational RFC, Nov 2007. > > 2. "Survey of Encoding and Transport Choices of > > (Pre-)Congestion Information > > within a DiffServ Domain", Informational RFC, Nov 2007. > > 3. "(Pre-)Congestion Detection within a DiffServ Domain", Proposed > > Standard RFC, > > Mar 2008. > > > > > > Discussion Results: List of volunteers interested to work on this draft: > > Kwok Ho Chan, Tina Tsou, Ken Young, Joe Babiarz, Ruediger Geib, > > Micheal Menth, > > Philip Eardley, Anna Charny > > > > For "Flow Admission and Termination Architecture within a > > Diffserv Domain": > > - We want this document to be at a high level, somewhere > > between the current > > Problem Statement draft and the CL Arch draft. > > - > > - Action Items: > > 1. Philip Eardley to take architectural sections from the current > > CL-Arch draft and Problem > > Statement draft to create the first cut of the new WG work > > item #1. This is to be at > > a high level and should avoid the specific deployment model > > from the CL-Arch draft. > > 2. Kwok Ho Chan to create the initial Terminology Section for the > > WG work item #1. > > During our meeting, we determined we should try to have the > > terminology be part of > > the Architecture document to start, and move it to another > > draft later if we need to. > > We should try to keep the terminology section short and try to > > reuse previously defined > > terms whenever possible. > > 3. The above action items should be completed in April 2007. All > > volunteers for WG work > > item #1 (and others) should review/comment/add-to the > > first cut version. > > - Goal: We should have the second version (-01) ready for WG review > > before Chicago (69th) IETF. > > > > > > For "Survey of Encoding and Transport Choices of (Pre-)Congestion > > Information within a DiffServ Domain": > > - Need to have the Chairs clarify the meaning of "Transport Choices" > > for this WG work item. > > May want to start by having a discussion of this on the WG list. > > - Need to work closely with Sally Floyd on this. Need to use Sally's > > RFC on this topic as guidance. > > - List of volunteers interested to work on this draft: > > Kwok Ho Chan, Joe Babiarz, Georgios Karagiannis, Anna Charny > > - Action Items: > > 1. Georgios Karagiannis to take the Appendix C of current CL-PHB > > draft and create the > > first cut of the new WG work item #2. > > 2. All volunteers for WG work item #2 (and others) should > > review/comment/add-to the > > first cut version. > > - Goal: We should at least have the first version (-00) ready for WG > > review before Chicago (69th) IETF. > > > > > > For "(Pre-)Congestion Detection within a DiffServ Domain": > > - We agreed this work item milestone is the hardest one to > > meet because of the > > technical complexity and detail work required to execute this work > > item correctly. > > - During our discussion, we have identified that we may need another > > draft (a new > > WG Work Item) for the successful execution of this work item. > > A draft on Criteria for Comparison of the different methods of > > "(Pre-)Congestion Detection". > > - Joe Babiarz indicated there is a (Pre)Congestion Admission Control > > Detection draft > > (companion to the Explicit Marking (for Flow > > Termination/Pre-emption) draft) coming. > > - Need to indicate/include dependencies between Detection and > > Encoding. > > - Action Items: > > 1. Anna Charny to create the first cut of the "Criteria for > > Comparing Detection Methods" draft. > > Each methods' authors will provide Anna with list of criteria > > each thinks is needed. > > I think someone called this the "beauty contest rules" > > draft. :) > > Goal: Have at least the first version (-00) of this new draft > > ready before the Chicago (69th) IETF. > > 2. All "(Pre-)Congestion Detection Method" authors should continue > > to improve on their individual > > drafts. > > 3. Geogios Karagiannis, Shoichi Senda, and others may want to > > consider adding other > > Detection Method drafts. > > - Goal: Get the process started early for this difficult milestone. > > > > End of Kwok's Notes on the PCN Work Item Meeting on Thur March 22, > > 2007 @ Prague. > > > > > > At 12:18 AM 3/21/2007, Kwok-Ho Chan wrote: > > >Hi all: > > >Since the Monday PCN WG session at Prague IETF, couple of people > > >have approached me informally on the hall way, during breaks, etc, > > >indicated they would like to help in the PCN work items. > > > > > >I have talked to Steven (but did not get a chance to talk to > > Scott yet) > > >on holding a quick meeting while most of us are at Prague, > > >to get the work on the first couple of PCN WG work items started. > > >Steven have given his support on this. > > > > > >Hence how about a quick meeting: > > >When: Wed March 21, 2007 16:30 (20 minutes into the cookie break) > > >Where: IETF Registration Desk > > > > > >This will give us half an hour to talk before Plenary starts. > > >Notice we may overflow into the Plenary if necessary. > > > > > >The topic will be to get a good sense on who wants to do what and > > >how we may divide and focus on the different pieces. > > > > > >For people who can not attend, please send mail to the PCN list, > > >Chairs, or myself > > >if you choose to, on your interest and what, how you may > > want to help. > > > > > >Thank you for all the energy and interest and hope to see you at the > > >quick meeting > > >indicated above. > > >-- Kwok -- > > > > > > > > > > > > > > > > > >_______________________________________________ > > >PCN mailing list > > >PCN@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Apr 05 15:15: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 1HZXQE-0005dU-7J; Thu, 05 Apr 2007 15:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXQD-0005dJ-8f for pcn@ietf.org; Thu, 05 Apr 2007 15:15:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZXQ0-000743-10 for pcn@ietf.org; Thu, 05 Apr 2007 15:15:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2007 15:14:48 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l35JElMJ029251; Thu, 5 Apr 2007 15:14:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l35JEalS019479; Thu, 5 Apr 2007 19:14:47 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); Thu, 5 Apr 2007 15:14:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Preliminary minutes from IETF 68 meeting Date: Thu, 5 Apr 2007 15:14:42 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [PCN] Preliminary minutes from IETF 68 meeting thread-index: Acd3q7/oIHrz4t4KQ2e8XU5YsRUqcgAABN2g From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 05 Apr 2007 19:14:44.0577 (UTC) FILETIME=[AB57F510:01C777B6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17647; t=1175800487; x=1176664487; c=relaxed/simple; s=rtpdkim2001; 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]=20Preliminary=20minutes=20from=20IETF=2068=20me eting |Sender:=20 |To:=20; bh=wZvP7kgSI2koaT19R1HaGM2kV+K2CaLKPe5AJzpnEl4=; b=wPRLq6vl+lABlNA8g6D7STD1WlDhxMtI0hcgLRmaIfESEToU2LNF/tAtaqkRy5HhqAVDJ3D1 vWSVZIMD3j4pSYG+2EzARl+4rCkFb5f4Dvx1k5XxaYK2yjZLKDasON2Q; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f 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 Steven and all, A few comments/corrections below. Thanks, Anna >=20 > For those who attended the PCN meeting in Prague: >=20 > Please review the preliminary meeting minutes below, and send=20 > comments/corrections to the list. >=20 > Thanks to Dave Borman, Fred Baker, Anna Charny, and Spencer=20 > Dawkins for taking notes during the meeting, and thanks to=20 > Scott for editing them. >=20 >=20 > ----------------------------------- >=20 > Congestion & Pre-congestion Notification Working Group >=20 > March 19, 2007 >=20 > Meeting Minutes taken by Dave Borman, Fred Baker, Anna Charny=20 > and Spencer Dawkins >=20 > Chairs - Scott Bradner & Steven Blake >=20 > Pre-congestion notification working group > 19 March 2007 >=20 > o Administrivia >=20 > Scott Bradner gave a brief discussion of the fact that pcn is=20 > now a working group and needs to work to its charter.=20 > An opportunity was given to bash the agenda, and no bashing occurred. > =20 > =20 > o Charter review >=20 > Steve Blake read the charter to the working group. Especially=20 > on restrictions. One diffserv domain with trusted members. >=20 > Milestones are revised after consultation with ADs. A mix of=20 > Informational and Proposed Standard documents. Architecture=20 > document will be comprehensive, including security and OAM. >=20 > Lots of "may consider after completing" items - concatenated=20 > diffserv domains, etc. Would recharter to work on these. >=20 > Stuart Goldman pointed the group to a draft=20 > (draft-goldman-pcn) regarding PSTN interactions. The chairs=20 > suggested that this belonged on a non-working group list. > =20 > Scott: you can have non-wg discussion on non-wg items on=20 > non-wg mailing lists. > =20 > =20 > o PCN Flow Admission and Termination Architecture =20 > Kwok-Ho Chan (see slides) >=20 > Kwok gave an overview of previous work by himself, Josef=20 > Babiarz, Bob Briscoe, and others.=20 >=20 > Scott noted that while this is prior work, it is not=20 > grandfathered as the approach the working group is to take.=20 > The working group needs to look at the various proposals and=20 > decide on an approach. >=20 > The key concepts are given in the following documents: >=20 > http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture > "An edge-to-edge Deployment Model for Pre-Congestion Notification: > Admission Control over a DiffServ Region", Bob Briscoe, 25-Oct-06, > =20 >=20 > http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb > "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06, > =20 >=20 > http://tools.ietf.org/html/draft-chan-pcn-problem-statement > "Pre-Congestion Notification Problem Statement", Kwok Ho=20 > Chan, 25-Oct-06, > =20 >=20 > Architectural considerations came out while writing the=20 > problem statement that need to be considered in the=20 > architecture, including the distinction between functions of=20 > the data plane and functions of the end systems that=20 > interpret its results. >=20 > Kwok commented that there was value in thinking this should=20 > be thought about in a trans-domain fashion. PCN architecture=20 > discussions talk about interior nodes and edge nodes.=20 > Interior nodes mark, edge nodes use marking for flow=20 > admission and termination decisions. >=20 > Architecture and problem statements probably need to be merged. >=20 > Have done some work on traffic measurement with simulation=20 > work. Done to provoke thought. Is the architecture the=20 > subset or the superset? >=20 > Lars: The WG would focus on single diffserv domain. Need to=20 > get marking semantics right, will be difficult to change=20 > later. Can't change diffserv architecture, but can add to it. >=20 > Tina Tsou - Will have general architecture as superset, right? Right. >=20 > Bob Briscoe: is concerned about designing the architecture=20 > for a single domain. He would argue for designing for the=20 > Internet and figuring how to use it in a single domain. >=20 > Lars: part of the issue is trust domains. We need to be able=20 > to design the mechanisms assuming that we are within a common=20 > trust domain first, and then figure out trans-domain. >=20 > Bob Briscoe - thought we needed to look at multi-domain.=20 > Diffserv was multi-domain. >=20 > Scott - focus was on what a router does, regardless of domain. >=20 > Lars - if you have multi-domain, you have to talk about=20 > security story. > IESG thought single domain was best understood. We can=20 > discuss when we see the single domain work. >=20 > Scott - would be premature to work on multi-domain if you=20 > don't have single domain yet. You can publish an individual=20 > draft individual draft using "pcn" in the file name even if=20 > the topic was beyond the scope of the WG, although it would=20 > not be discussed in the working group. >=20 > ?Woody?Govat? wants to know whether trans-domain work should=20 > go to the transport working group.=20 >=20 > Lars - not in TSVWG - too confusing to talk in two places at once. >=20 > Bob Briscoe - the picture of PCN arch isn't the whole internet, just a > (big) hop (conceptually an AS). >=20 > Scott - there are a number of constructs on how the internet.=20 > E.g., a single ISP can have multiple domains. Our charter=20 > says one domain. We can say there are other scenarios and=20 > multi-domain situations, but leave it as that without going further. >=20 > Scott: markings don't leak, but are interpreted by an edge=20 > box. Making a statement in the architecture document about=20 > leaking markers and trust between domains as issues can be=20 > stated, but we don't have to go into them. >=20 > Bob: Assume when we get to multi-domain, we'll need a new architecture > document: >=20 > Question: what did we agree on? >=20 > Scott: We agreed to follow the working group charter. >=20 > Steven: we have an 18 month schedule. There'll be plenty of=20 > time to move onward after that. >=20 > Kwok continued with a discussion of the duties of an interior=20 > node, which boil down to simply, scalably, and interoperably=20 > calculate throughput and congestion indicators and mark=20 > traffic accordingly.=20 > The edge node needs then to do the right thing with the=20 > aggregate of those marks, which may include dropping packets=20 > or triggering application behavior such as terminating sessions. >=20 > Kwok noted that we need common terminology. A show of hands=20 > suggested that including a glossary in the architecture draft=20 > makes the most sense. Lars noted that using diffserv=20 > terminology where applicable would be wise. >=20 > Anna Charny suggested that the people who may want to work on=20 > the terminology may not be the same people who will want to=20 > work on the architecture..=20 >=20 > Lars - reuse diffserv terminology (please). >=20 > Expecting impact on architecture from flow rate adaption,=20 > cheating detection, multi-domain, application control. Don't=20 > want Interior Nodes to change if we work on these items. >=20 > Basically, the architecture and terminology are not complete=20 > until that issue is settled. >=20 > Kwok also mentioned several non-goals need to be considered=20 > while designing the architecture. >=20 > Lars noted that standards track outputs of this working group=20 > should not change when the matter goes trans-domain.=20 > This of course has implications - trans-domain needs to be=20 > thought about enough to prevent such rework. >=20 > Joe Evers asked whether it would be appropriate to have=20 > individual submissions for various parts of the non-goal=20 > discussions. Scott indicated that doing non-goal work tends=20 > to disrupt the progress of the working group. >=20 > Bob Briscoe, commented that the scoping issue may make it=20 > difficult to produce a stable transdomain solution in a=20 > single-domain effort. >=20 > Kwok also discussed a survey of encoding. He indicated that=20 > the DSCP could be used if PHBs are reworked to allow for=20 > additional coding. >=20 > Chris Christou noted the Hiccup BOF, where the applicability=20 > to emergency communications may be discussed. >=20 > Tina Tsou asked whether the measurements occurred on=20 > aggregates between ingress/egress pairs.=20 >=20 > Kwok - diffserv traffic aggregates within a single diffserv=20 > domain are under consideration here. >=20 > Scott suggested that the best way to compare marking=20 > strategies was multiple drafts by the proponents. =20 >=20 > Josef Babiarz indicated that it would be better in a common draft.=20 >=20 > Dave McDysan suggested that measures of comparison including=20 > performance would be good to include in the performance=20 > metrics. Need to agree on methods of comparison of different=20 > need to agree on criteria for comparison of different=20 > approaches. He suggested compiling a common draft from=20 > several separate drafts. >=20 > Scott: idea of comparison criteria is useful; need to develop that > =20 > o Performance Evaluation of CL-PHB Admission and pre-emption=20 > Algorithms Joy Zhang =20 >=20 > Joy discussed simulation experiments the authors have been=20 > doing to validate the architecture. They simulated CBR,=20 > on/off voice, synthetic video, and a real video trace.=20 >=20 > Her previously reported admission observations were that when=20 > correctly configured the algorithm worked well on links that=20 > had a high ratio of capacity to individual session size. >=20 > Dave McDysan commented that the results should have some=20 > measure of the real effect. Anna Charny indicated that the =20 > testing Joy was reporting showed over-admission percentage=20 > rather than over-preemption. It is a milder statement than the above. >=20 My understanding is that Dave's question was about how over-admission percentage affects real users whose calls may be dropped. My answer was that overadmission in these experiments should notresult in dropping any calls unnecessarily - but over-preemption could. > Preemption/Termination observations were that over-preemption=20 > was possible, especially in a long RTT channel, since it=20 > depends on the probable view as seen by differing systems. If=20 > all edge devices preempt at the same ECN-CE density and all=20 > flows in an aggregate are marked with the same probability,=20 > one would expect all sessions to drop simultaneously with=20 > some probability when only a few need to.=20 The last sentense was n the context of explaining theoretical worst case, not the simulation results. >=20 > With multiple bottlenecks, a situation an occur in which one=20 > bottleneck can see variation in load when a second bottleneck=20 > builds on its marks to mark traffic. She noted that in her=20 > simulations this was not as much of a problem as expected. >=20 > Georgios Karagiannis - Have you looked into marked/unmarked=20 > packets are lost? >=20 > Joy: No. Simulations assume all packets get through: >=20 > Anna Charney: Only assume that some of the marked packets get through. >=20 Correction to my name: there is no "e" in Charny > Argenous ? wanted to know how many sources one needed to make=20 > PCN work. > Joy said that estimates of such were in her draft. >=20 > ???: How does a PCN enabled router mark with different RTTs? >=20 > Steve: In the charter, we only assume inelastic flows. >=20 > Anna Charney: Differences in RTT didn't have much of an effect >=20 Correction to my name again: there is no "e" in Charny =20 > o Pre-Congestion Notification Using Single Marking for Admission and > Pre-emption =20 > Anna Charny > =20 >=20 > Have written overview that follows PCN drafts closely. Want=20 > to talk about tradeoffs and next steps. >=20 > Core just does marking, egress measures unmarked traffic.=20 > Works like preemption in CL drafts except that there's only=20 > one marking. Ingress computes sustainable flow termination rate. >=20 > Good - save one codepoint (important with MPLS), one metering=20 > measurement. >=20 > Bad - not sure how to change K parameter system-wide,=20 I believe I said that the approach requires that one needs to set parameter K to be the same system-wide, rather than "not sure how to change" it.=20 > excess-rate admission control is more sensitive to parameters=20 > and traffic patterns, conflicts with Bob Briscoe=20 > anti-cheating mechanism. >=20 > Does WG need to choose between two (or more) mechanisms, or=20 > is there a way to include them all in the standard? >=20 > May be able to define single-marking as a subset of=20 > two-threshold marking behavior. If only some core devices=20 > support type 1 and type 2, must all revert to type 1 and be=20 > configured with the same K constant. >=20 I explained that "type 1" marking is "excess rate" marking and "type 2" marking is the "virtual-queue-based" marking. Both are already defined in draft-brisco-cl-architecture drafts. > Single-marking appears technically viable - fewer=20 > implementation changes to existing core equipment, smaller=20 > performance impact in data path of core routers. > I think the text below marked &&&& is a duplicate of the text a few pars down, marked ***** &&& begin text that I think is a duplicate, and must go further down &&&& > Have you looked a ECMP with multihopping? Only choose flows=20 > that have been marked. Not sure if we can just ignore this -=20 > don't do anything. The above was a question by Joe Babiarz > This is an open question. > There is a problem even with per-flow load balancing across=20 > multiple paths. I do not believe I mentioned per-flow load-balancing. I said that the ECMP can be a cause of a potential problem for not just single-marking approach, but also for the "two-marking" approach in draft-briscoe-cl-arcitecture >=20 > Looked at aggregates with different numbers of flows?=20 Also Joe Babiarz's question >Not yet, don't see why it would change, want to understand why=20 > you think this is a problem. > When everyone has a small number of flows, that's probably worst-case. >=20 And we simulated that case > On-off patterns are already included in simulations. &&&& end of what I think is duplicate text &&&& >=20 > Does anyone see any major holes? >=20 ****** I believe the text marked &&& above should correspond to questions below: ******* > Joe Babiarz - How with multi-path routing? >=20 > Anna: When you preempt, can we just not do anything? You=20 > might pick the wrong one, but hopefully over time it will work >=20 I believe I said that it may be possible that just doing nothing may not be to bad from performance standpoint. I also said that the problem with ECMP may be solved if the ingress only chooses amoung those flows that are already marked when it selects flows for pre-emption. > Scott: if you hash the high order bits in route selection, is=20 > there a problem? >=20 > Joe: yes - The assumption is that one route is congested, and=20 > the other isn't. >=20 > Joe: Have you considered a disparity in the number of flows? >=20 > Anna: doesn't matter much. Worst case is when everyone has a=20 > small number of flows. >=20 > Joe: When you have on-off traffic, is during your=20 > measurements? Say 40/60, how do you address the error when=20 > the 40 percent isn't sending? >=20 > Anna: We don't address that error. I believe I said something diferent. I said that we do not do anything about this because our simulations alreadt include such on-off traffic with lon periods of silence, and our results *include* that on-off effect.=20 **** this is the end of duplicated set of questions, I think ***** >=20 > Bob: Are you saying it's easier to use a token bucket for this? >=20 > Anna: the marking here is the same as it is today. The token=20 > marking of the virtual queue will require more work. >=20 > Jozef Babiarz: #flows is calculated at ingress. Another way=20 > is to calculate at egress. Is that a difference? >=20 > Anna: it doesn't change things for these measurements, but it=20 > can be looked at. >=20 > Anna: should the WG consider allowing two or more options? =20 > Or should there be just one? >=20 > Steve: There are tradeoffs, and performance is not the only=20 > one, or even the most important one. Implementation is important. >=20 > Scott: IPR consideration is another item. The Cisco IPR=20 > statement is fine, it's been accepted in some WGs, and=20 > rejected in others. >=20 > Lars: One reason that the encoding is a proposed standard is=20 > for interoperability. If you have multiple versions, you=20 > fragment the solution space. The initial hope was for one=20 > solution that is good enough for most situations. Unclear if=20 > this is a clever renaming or if there is a conflict. >=20 > o Explicit PCN Marking > Jozef Babiarz > =20 >=20 > This is only for flow termination, not admission control. >=20 > Want to stay above Admissible rate, but below Supportable rate. >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Apr 11 17:15: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 1Hbk9v-0006QL-CI; Wed, 11 Apr 2007 17:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbk9t-0006QF-5v for pcn@ietf.org; Wed, 11 Apr 2007 17:15:17 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbk9p-0006EW-AN for pcn@ietf.org; Wed, 11 Apr 2007 17:15:17 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l3BLDZ94006581 for ; Wed, 11 Apr 2007 16:13:35 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:15:10 -0500 Received: from [147.117.169.165] ([147.117.169.165]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:15:10 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-eQpwY77lo+tBVQnpFF/V" Organization: Ericsson IP Infrastructure Date: Wed, 11 Apr 2007 17:15:09 -0400 Message-Id: <1176326109.3287.13.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 11 Apr 2007 21:15:10.0231 (UTC) FILETIME=[7CA5C270:01C77C7E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f Subject: [PCN] Official minutes from IETF 68 meeting 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 --=-eQpwY77lo+tBVQnpFF/V Content-Type: text/plain Content-Transfer-Encoding: 7bit I have edited the preliminary minutes, based on feedback from Jozef Babiarz and Anna Charny, and have submitted the official minutes (attached). Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson Data Networks +1 919-472-9913 --=-eQpwY77lo+tBVQnpFF/V Content-Disposition: attachment; filename=pcn-ietf68-minutes.txt Content-Type: text/plain; name=pcn-ietf68-minutes.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion & Pre-congestion Notification (PCN) Working Group Meeting Minutes IETF 68 - Prague March 19, 2007 Meeting Minutes taken by Dave Borman, Fred Baker, Anna Charny and Spencer Dawkins Chairs - Scott Bradner & Steven Blake o Administrivia Scott Bradner gave a brief discussion of the fact that pcn is now a working group and needs to work to its charter. An opportunity was given to bash the agenda, and no bashing occurred. o Charter review Steve Blake read the charter to the working group. Especially on restrictions. One diffserv domain with trusted members. Milestones are revised after consultation with ADs. A mix of Informational and Proposed Standard documents. Architecture document will be comprehensive, including security and OAM. Lots of "may consider after completing" items - concatenated diffserv domains, etc. Would recharter to work on these. Stuart Goldman pointed the group to a draft (draft-goldman-pcn) regarding PSTN interactions. The chairs suggested that this belonged on a non-working group list. Scott: you can have non-wg discussion on non-wg items on non-wg mailing lists. o PCN Flow Admission and Termination Architecture Kwok-Ho Chan (see slides) Kwok gave an overview of previous work by himself, Josef Babiarz, Bob Briscoe, and others. Scott noted that while this is prior work, it is not grandfathered as the approach the working group is to take. The working group needs to look at the various proposals and decide on an approach. The key concepts are given in the following documents: http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region", Bob Briscoe, 25-Oct-06, http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06, http://tools.ietf.org/html/draft-chan-pcn-problem-statement "Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25-Oct-06, Architectural considerations came out while writing the problem statement that need to be considered in the architecture, including the distinction between functions of the data plane and functions of the end systems that interpret its results. Kwok commented that there was value in thinking this should be thought about in a trans-domain fashion. PCN architecture discussions talk about interior nodes and edge nodes. Interior nodes mark, edge nodes use marking for flow admission and termination decisions. Architecture and problem statements probably need to be merged. Have done some work on traffic measurement with simulation work. Done to provoke thought. Is the architecture the subset or the superset? Lars: The WG would focus on single diffserv domain. Need to get marking semantics right, will be difficult to change later. Can't change diffserv architecture, but can add to it. Tina Tsou - Will have general architecture as superset, right? Right. Bob Briscoe: is concerned about designing the architecture for a single domain. He would argue for designing for the Internet and figuring how to use it in a single domain. Lars: part of the issue is trust domains. We need to be able to design the mechanisms assuming that we are within a common trust domain first, and then figure out trans-domain. Bob Briscoe - thought we needed to look at multi-domain. Diffserv was multi-domain. Scott - focus was on what a router does, regardless of domain. Lars - if you have multi-domain, you have to talk about security story. IESG thought single domain was best understood. We can discuss when we see the single domain work. Scott - would be premature to work on multi-domain if you don't have single domain yet. You can publish an individual draft individual draft using "pcn" in the file name even if the topic was beyond the scope of the WG, although it would not be discussed in the working group. ?Woody?Govat? wants to know whether trans-domain work should go to the transport working group. Lars - not in TSVWG - too confusing to talk in two places at once. Bob Briscoe - the picture of PCN arch isn't the whole internet, just a (big) hop (conceptually an AS). Scott - there are a number of constructs on how the internet. E.g., a single ISP can have multiple domains. Our charter says one domain. We can say there are other scenarios and multi-domain situations, but leave it as that without going further. Scott: markings don't leak, but are interpreted by an edge box. Making a statement in the architecture document about leaking markers and trust between domains as issues can be stated, but we don't have to go into them. Bob: Assume when we get to multi-domain, we'll need a new architecture document: Question: what did we agree on? Scott: We agreed to follow the working group charter. Steven: we have an 18 month schedule. There'll be plenty of time to move onward after that. Kwok continued with a discussion of the duties of an interior node, which boil down to simply, scalably, and interoperably calculate throughput and congestion indicators and mark traffic accordingly. The edge node needs then to do the right thing with the aggregate of those marks, which may include dropping packets or triggering application behavior such as terminating sessions. Kwok noted that we need common terminology. A show of hands suggested that including a glossary in the architecture draft makes the most sense. Lars noted that using diffserv terminology where applicable would be wise. Anna Charny suggested that the people who may want to work on the terminology may not be the same people who will want to work on the architecture.. Lars - reuse diffserv terminology (please). Expecting impact on architecture from flow rate adaption, cheating detection, multi-domain, application control. Don't want Interior Nodes to change if we work on these items. Basically, the architecture and terminology are not complete until that issue is settled. Kwok also mentioned several non-goals need to be considered while designing the architecture. Lars noted that standards track outputs of this working group should not change when the matter goes trans-domain. This of course has implications - trans-domain needs to be thought about enough to prevent such rework. Joe Evers asked whether it would be appropriate to have individual submissions for various parts of the non-goal discussions. Scott indicated that doing non-goal work tends to disrupt the progress of the working group. Bob Briscoe, commented that the scoping issue may make it difficult to produce a stable transdomain solution in a single-domain effort. Kwok also discussed a survey of encoding. He indicated that the DSCP could be used if PHBs are reworked to allow for additional coding. Chris Christou noted the Hiccup BOF, where the applicability to emergency communications may be discussed. Tina Tsou asked whether the measurements occurred on aggregates between ingress/egress pairs. Kwok - diffserv traffic aggregates within a single diffserv domain are under consideration here. Scott suggested that the best way to compare marking strategies was multiple drafts by the proponents. Josef Babiarz indicated that it would be better in a common draft. Dave McDysan suggested that measures of comparison including performance would be good to include in the performance metrics. Need to agree on methods of comparison of different need to agree on criteria for comparison of different approaches. He suggested compiling a common draft from several separate drafts. Scott: idea of comparison criteria is useful; need to develop that o Performance Evaluation of CL-PHB Admission and pre-emption Algorithms Joy Zhang Joy discussed simulation experiments the authors have been doing to validate the architecture. They simulated CBR, on/off voice, synthetic video, and a real video trace. Her previously reported admission observations were that when correctly configured the algorithm worked well on links that had a high ratio of capacity to individual session size. Dave McDysan commented that the results should have some measure of the real effect. How did over-admission percentage affect real users whose calls may be dropped. Anna Charny indicated that the testing Joy was reporting showed over-admission percentage rather than over-preemption. Over-admission in these experiments should not result in dropping any calls unnecessarily, but over-preemption could. It is a milder statement than the above. Preemption/Termination observations were that over-preemption was possible, especially in a long RTT channel, since it depends on the probable view as seen by differing systems. If all edge devices preempt at the same ECN-CE density and all flows in an aggregate are marked with the same probability, one would expect all sessions to drop simultaneously with some probability when only a few need to (this is a theoretical observation, not something seen in the simulation results). With multiple bottlenecks, a situation an occur in which one bottleneck can see variation in load when a second bottleneck builds on its marks to mark traffic. She noted that in her simulations this was not as much of a problem as expected. Georgios Karagiannis - Have you looked into marked/unmarked packets are lost? Joy: No. Simulations assume all packets get through: Anna Charny: Only assume that some of the marked packets get through. Argenous ? wanted to know how many sources one needed to make PCN work. Joy said that estimates of such were in her draft. ???: How does a PCN enabled router mark with different RTTs? Steve: In the charter, we only assume inelastic flows. Anna Charny: Differences in RTT didn't have much of an effect o Pre-Congestion Notification Using Single Marking for Admission and Pre-emption Anna Charny Have written overview that follows PCN drafts closely. Want to talk about tradeoffs and next steps. Core just does marking, egress measures unmarked traffic. Works like preemption in CL drafts except that there's only one marking. Ingress computes sustainable flow termination rate. Ingress computes sustainable flow termination rate from the marking observed, and also uses this marking for admission decision. Good - save one codepoint (important with MPLS), one metering measurement. Bad - Must set K parameter consistently system-wide; excess-rate admission control is more sensitive to parameters and traffic patterns, conflicts with Bob Briscoe's anti-cheating mechanism. Does WG need to choose between two (or more) mechanisms, or is there a way to include them all in the standard? May be able to define single-marking as a subset of two-threshold marking behavior. If only some core devices support type 1 and type 2, must all revert to type 1 and be configured with the same K constant. Type 1 marking is based on "excess rate", and Type 2 marking is based on "virtual queue-based" marking, as already defined in draft-briscoe-cl-architecture. Single-marking appears technically viable - fewer implementation changes to existing core equipment, smaller performance impact in data path of core routers. Does anyone see any major holes? Joe Babiarz - How does it work with multi-path routing? Anna: It may be possible that just doing nothing may not be to bad from performance standpoint. Also, the problem with ECMP may be solved if the ingress only chooses amoung those flows that are already marked when it selects flows for pre-emption. Both single-marking and draft-briscoe-cl-architecture both have the same issue with EC Scott: if you hash the high order bits in route selection, is there a problem? Joe: yes - The assumption is that one route is congested, and the other isn't. Joe: Have you considered a disparity in the number of flows? Anna: This should not matter much. Worst case is when everyone has a small number of flows, and we simulated that. Joe: When you have on-off traffic, is during your measurements? Say 40/60, how do you address the error when the 40 percent isn't sending? Anna: We don't explicitly address that error. Our simulations already include such on-off traffic with long periods of silence, and our results include that on-off effect. Bob: Are you saying it's easier to use a token bucket for this? Anna: the marking here is the same as it is today. The token marking of the virtual queue will require more work. Jozef Babiarz: #flows is calculated at ingress. Another way is to calculate at egress. Is that a difference? Anna: it doesn't change things for these measurements, but it is a change to the currently proposed architecture. Anna: should the WG consider allowing two or more options? Or should there be just one? Steve: There are tradeoffs, and performance is not the only one, or even the most important one. Implementation is important. Scott: IPR consideration is another item. The Cisco IPR statement is fine, it's been accepted in some WGs, and rejected in others. Lars: One reason that the encoding is a proposed standard is for interoperability. If you have multiple versions, you fragment the solution space. The initial hope was for one solution that is good enough for most situations. Unclear if this is a clever renaming or if there is a conflict. o Explicit PCN Marking Jozef Babiarz This is only for flow termination, not admission control. Want to stay above Admissible rate, but below Supportable rate. Mark packets above supportable rate. The charts show two failure situations. One, fast failover, second slowly transition traffic (80% within one second, and the remaining 20% within 5 seconds). Ingress routers mark packets, egress routers monitor packets for congestion markings, and signal what flows are marked to ingress routers. Ingress routers perform flow termination. Have done simulation for voice, video, etc. Preemption does work, but really bursty traffic needs a large token bucket. Termination happens when preemption doesn't happen. This is a different tradeoff than previous presentation - react quickly, or avoid over-preemption. WG needs to discuss what we want to happen. As part of definition, need to decide how fast we need to converge. Before people timeout and hang up - that's too late. RTT doesn't matter - do different RTTs in the same network matter? Expect parameters would be selected based on longest RTT in the system, in which case RTT doesn't matter. Bob Briscoe: Preemption or flow termination is a last resort when other things haven't worked. Joy was describing a situation to preempt as fast as possible, Joe's is to do preemption slower. ???: Joe commented several times it works well, it is personal preference on what "works well" means. How fast do you need things to converge? If people hang up before things converge, that's a problem. Scott: you need to think about the human reaction time, not just the system reaction time. If the human time is faster, that's not good. Joe: simulated different RTTs (2 msec to 800 msec, and reaction time was different for each value. Results presented showed that for RTT of 50 msec, flow termination took less than one second to bring load down to a supportable rate. Anna: does it matter when you have different RTTs in the same network? Joe: we haven't tested that. Lars: The point is to alleviate congestion quickly. It would be useful to stick to that. Scott: The term "quickly" is not easily defined. o Next Steps for WG... Scott: How do we move forward? The authors that are up already, should make sure the documents are concurrent with the charter. If you think it is consistent with the charter, then send it to the chairs and the mailing list will be used to get consensus. Volunteers are wanted for the documents on the to-do list. Chris ???: BOF is at 11:50 AM in Congress I. --=-eQpwY77lo+tBVQnpFF/V 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 --=-eQpwY77lo+tBVQnpFF/V-- From pcn-bounces@ietf.org Thu Apr 26 09: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 1Hh3mL-0008Nt-8b; Thu, 26 Apr 2007 09:12:57 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hh3mJ-0008NN-3r for pcn-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 09:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3mF-0008LW-Uu for pcn@ietf.org; Thu, 26 Apr 2007 09:12:51 -0400 Received: from protext01.itu.ch ([156.106.192.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh3mD-0001cK-Cb for pcn@ietf.org; Thu, 26 Apr 2007 09:12:51 -0400 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Apr 2007 15:12:45 +0200 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR2); id 1177593163804; Thu, 26 Apr 2007 15:12:43 +0200 Received: from IBM4307EA0CEF3 ([156.106.204.85]) by mail6.itu.ch (8.13.8/8.14.0) with ESMTP id l3QDCbt8318608; Thu, 26 Apr 2007 15:12:42 +0200 (MEST) Message-ID: <021201c78804$917ca420$55cc6a9c@IBM4307EA0CEF3> From: "Tina TSOU" To: References: Date: Thu, 26 Apr 2007 15:12:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail6.itu.ch [156.106.192.22]); Thu, 26 Apr 2007 15:12:43 +0200 (MEST) X-OriginalArrivalTime: 26 Apr 2007 13:12:45.0320 (UTC) FILETIME=[94551880:01C78804] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [PCN] Upgrade/Downgrade QoS 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 Guys, I thought about "Upgrade/Downgrade" QoS these days. Downgrade QoS: "NGN be capable, in certain conditions, to change or "degrade" the current QoS enforcement settings associated with an ongoing reservation in order to admit new flows beyond the available QoS levels." In PCN, besides admission control, there is pre-emption, to cast off selectively the existing service packet in the edge node. "Upgrade/Downgrade" is a good QoS control mechanism. Does someone have similar thought as I do? B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Apr 26 09:58: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 1Hh4U9-0000vp-Os; Thu, 26 Apr 2007 09:58:13 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hh4U8-0000qe-B9 for pcn-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 09:58:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4U8-0000qT-1c for pcn@ietf.org; Thu, 26 Apr 2007 09:58:12 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh4U6-0001jZ-P9 for pcn@ietf.org; Thu, 26 Apr 2007 09:58:12 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3QDvRp23408; Thu, 26 Apr 2007 13:57:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Upgrade/Downgrade QoS Date: Thu, 26 Apr 2007 09:58:03 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650FEB8BCE@zcarhxm1.corp.nortel.com> In-Reply-To: <021201c78804$917ca420$55cc6a9c@IBM4307EA0CEF3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Upgrade/Downgrade QoS thread-index: AceIBKGnoA+By2NPSMed3mlcDnOzDgABF2HQ From: "Jozef Babiarz" To: "Tina TSOU" , 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 Tina,=20 Yes, PCN can be used to do other things besides flow block and flow termination. However, the current scope of the PCN WG as stated in our charter is to focus on two reactions mechanisms, admission control and flow termination. The Upgrade/Downgrade concept can be brought for consideration when the WG re-charters.=20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: April 26, 2007 9:13 AM To: pcn@ietf.org Subject: [PCN] Upgrade/Downgrade QoS Hi Guys, I thought about "Upgrade/Downgrade" QoS these days. Downgrade QoS: "NGN be capable, in certain conditions, to change or=20 "degrade" the current QoS enforcement settings associated with an ongoing=20 reservation in order to admit new flows beyond the available QoS levels." In PCN, besides admission control, there is pre-emption, to cast off=20 selectively the existing service packet in the edge node.=20 "Upgrade/Downgrade" is a good QoS control mechanism. Does someone have similar thought as I do? B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber:=20 tina@jabber.org Google talk: tinatsou6@gmail.com=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 Apr 26 10:13: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 1Hh4it-0004nI-7a; Thu, 26 Apr 2007 10:13:27 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hh4ir-0004nD-Pg for pcn-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 10:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4ir-0004n4-G7 for pcn@ietf.org; Thu, 26 Apr 2007 10:13:25 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh4io-0003fY-Hv for pcn@ietf.org; Thu, 26 Apr 2007 10:13:25 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 7F3ADAC24F0; Thu, 26 Apr 2007 22:13:16 +0800 (CST) Message-ID: <000801c7880d$087842c0$a507740a@DELLWEI> From: "Wei Gengyu" To: "Tina TSOU" References: <021201c78804$917ca420$55cc6a9c@IBM4307EA0CEF3> Subject: Re: [PCN] Upgrade/Downgrade QoS Date: Thu, 26 Apr 2007 22:13:15 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Content-Type: multipart/mixed; boundary="===============1542975847==" Errors-To: pcn-bounces@ietf.org --===============1542975847== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQpJIHRoaW5rIHRoYXQgcGVvcGxlIG9mdGVuIHBheSB3aGF0IHRoZXkgd2FudDsNCnNvbWV0aW1l cywgdGhleSBwYXkgd2hhdCB0aGV5IGhhdmUgZ290Lg0KDQpJZiB0aGUgUW9TIGlzIHdoYXQgdGhl eSB3YW50LCB0aGUgbmV0d29yayBzaG91bGQgZ3VhcmFudGVlIHRoYXQuDQpBbmQgaWYgdGhlIFFv UyBpcyBwYWlkIGJ5IHdoYXQgdGhleSBoYXZlIGdvdCwgZG93bmdyYWRlIFFvUyBtYXkgd29yay4g DQoNClJlZ2FyZHMsIA0KDQpHZW5neXUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206ICJUaW5hIFRTT1UiIDx0ZW5hQGh1YXdlaS5jb20+DQpUbzogPHBjbkBpZXRmLm9yZz4N ClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNiwgMjAwNyA5OjEyIFBNDQpTdWJqZWN0OiBbUENOXSBV cGdyYWRlL0Rvd25ncmFkZSBRb1MNCg0KDQo+IEhpIEd1eXMsDQo+IEkgdGhvdWdodCBhYm91dCAi VXBncmFkZS9Eb3duZ3JhZGUiIFFvUyB0aGVzZSBkYXlzLg0KPiBEb3duZ3JhZGUgUW9TOiAiTkdO IGJlIGNhcGFibGUsIGluIGNlcnRhaW4gY29uZGl0aW9ucywgdG8gY2hhbmdlIG9yIA0KPiAiZGVn cmFkZSIgdGhlIGN1cnJlbnQgUW9TIGVuZm9yY2VtZW50IHNldHRpbmdzIGFzc29jaWF0ZWQgd2l0 aCBhbiBvbmdvaW5nIA0KPiByZXNlcnZhdGlvbiBpbiBvcmRlciB0byBhZG1pdCBuZXcgZmxvd3Mg YmV5b25kIHRoZSBhdmFpbGFibGUgUW9TIGxldmVscy4iDQo+IEluIFBDTiwgYmVzaWRlcyBhZG1p c3Npb24gY29udHJvbCwgdGhlcmUgaXMgcHJlLWVtcHRpb24sIHRvIGNhc3Qgb2ZmIA0KPiBzZWxl Y3RpdmVseSB0aGUgZXhpc3Rpbmcgc2VydmljZSBwYWNrZXQgaW4gdGhlIGVkZ2Ugbm9kZS4gDQo+ ICJVcGdyYWRlL0Rvd25ncmFkZSIgaXMgYSBnb29kIFFvUyBjb250cm9sIG1lY2hhbmlzbS4NCj4g RG9lcyBzb21lb25lIGhhdmUgc2ltaWxhciB0aG91Z2h0IGFzIEkgZG8/DQo+IA0KPiBCLiBSLg0K PiBUaW5hDQo+IE1lc3NlbmdlcnM6DQo+IE1TTjogdGluYXRzb3U2QGhvdG1haWwuY29tICAgWWFo b286IHRpbmFfdHNvdSAgICBTa3lwZTogdGluYVRTT1UgICAgSmFiYmVyOiANCj4gdGluYUBqYWJi ZXIub3JnICAgIEdvb2dsZSB0YWxrOiB0aW5hdHNvdTZAZ21haWwuY29tIA0KPiANCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBQQ04g bWFpbGluZyBsaXN0DQo+IFBDTkBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wY24NCj4= --===============1542975847== 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 --===============1542975847==-- From pcn-bounces@ietf.org Thu Apr 26 13:08: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 1Hh7Rn-0004CF-VI; Thu, 26 Apr 2007 13:07:59 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hh7Rn-0004CA-DF for pcn-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:07:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7Rn-0004C2-3l for pcn@ietf.org; Thu, 26 Apr 2007 13:07:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7Rl-0001AH-Nl for pcn@ietf.org; Thu, 26 Apr 2007 13:07:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2007 10:07:58 -0700 X-IronPort-AV: i="4.14,456,1170662400"; d="scan'208"; a="415974956:sNHT47321408" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3QH7vAu013428; Thu, 26 Apr 2007 10:07:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3QH7vMF004702; Thu, 26 Apr 2007 17:07:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:07:56 -0700 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:07:56 -0700 In-Reply-To: <021201c78804$917ca420$55cc6a9c@IBM4307EA0CEF3> References: <021201c78804$917ca420$55cc6a9c@IBM4307EA0CEF3> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [PCN] Upgrade/Downgrade QoS Date: Thu, 26 Apr 2007 10:07:56 -0700 To: Tina TSOU X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Apr 2007 17:07:56.0586 (UTC) FILETIME=[6F4D68A0:01C78825] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1292; t=1177607277; x=1178471277; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20Upgrade/Downgrade=20QoS |Sender:=20; bh=33+/d7uOeZslNdQITQ/yC+ezGiQEqu2huojSOj4mQEE=; b=M+9alYzKqKaLHyHc2f/rmhNrS/Tgm+AAwK2D0NRL/wsWLFgJu6jq45q12wCrEKXaWoFZQNDR B3Fv/IJ/C9std3wQCX0oKIABzGWYn0M0Hvu5R8COj3BYTXAJIBz2Hxpp; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Apr 26, 2007, at 6:12 AM, Tina TSOU wrote: > In PCN, besides admission control, there is pre-emption, to cast > off selectively the existing service packet in the edge node. > "Upgrade/Downgrade" is a good QoS control mechanism. Not all networks allow preemption. For civilian networks in the United States, you will want to not allow the data flow in, not shut it down after it has occurred. Also, while some networks (I'm thinking radio, including 802.11) change rates dynamically and so might change their admission parameters dynamically, in the general case I would expect admission parameters to remain stable. The thing that is likely to happen in which sessions degrade is the thing that stopped Morita-san's Priority Promotion Scheme http://www3.ietf.org/proceedings/03jul/slides/tsvwg-2.pdf http://tools.ietf.org/id/draft-morita-tsvwg-pps He wanted to use this scheme for both voice and video in the NTT network. For rate-variable video like MPEG-4, he found that it was very possible to have the video stream accepted during a relatively quiet period, and at a commercial break has bandwidth usage across all channels simultaneously jump by an order of magnitude, which had some pretty serious consequences. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Apr 27 02:51: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 1HhKIt-00032u-JC; Fri, 27 Apr 2007 02:51:39 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1HhKIt-00032o-3X for pcn-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 02:51:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKIo-0002zF-PI for pcn@ietf.org; Fri, 27 Apr 2007 02:51:34 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhKIm-0004PA-QV for pcn@ietf.org; Fri, 27 Apr 2007 02:51:34 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 27 Apr 2007 08:41:00 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 08:41:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Upgrade/Downgrade QoS Date: Fri, 27 Apr 2007 08:40:59 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB94ED@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <021201c78804$917ca420$55cc6a9c@IBM4307EA0CEF3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Upgrade/Downgrade QoS Thread-Index: AceIBKGTFePnh5LpRAOPbAHM9B6zkwAj4/JQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 27 Apr 2007 06:41:00.0106 (UTC) FILETIME=[048BD2A0:01C78897] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Tina, to my understanding PCN delivers a trigger to indicate some state of = approaching or existing congestion. Whether an operator interprets such = a trigger as "start preemption" or as "start downgrade to best effort" = may be up to him (and to the technical capabilities of the operated = equipment). Demotion to best effort would enable interesting business models. A = service provider could claim to support QoS and limit each links PCN = resources to a couple of kbit/s. The quality demotion during = "congestion" could be covered in a contracts small print.=20 This mode of operation can't be adopted easily, if the reaction on a = congestion indication is a busy sign. But in the end, decisions like = that are up to the providers operating services. Regards, Ruediger |-----Original Message----- |From: Tina TSOU [mailto:tena@huawei.com] |Sent: Thursday, April 26, 2007 3:13 PM |To: pcn@ietf.org |Subject: [PCN] Upgrade/Downgrade QoS | | |Hi Guys, |I thought about "Upgrade/Downgrade" QoS these days. |Downgrade QoS: "NGN be capable, in certain conditions, to change or=20 |"degrade" the current QoS enforcement settings associated with=20 |an ongoing=20 |reservation in order to admit new flows beyond the available=20 |QoS levels." |In PCN, besides admission control, there is pre-emption, to cast off=20 |selectively the existing service packet in the edge node.=20 | "Upgrade/Downgrade" is a good QoS control mechanism. |Does someone have similar thought as I do? | |B. R. |Tina |Messengers: |MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype:=20 |tinaTSOU Jabber:=20 |tina@jabber.org Google talk: tinatsou6@gmail.com=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