Congestion and Pre-Congestion Notification WG (pcn) IETF72 Meeting Minutes CHAIRs: Scott Bradner Steven Blake Notetakers: Peter McCann Tom Taylor THURSDAY, July 31, 2008 0900-1130 Morning Session I Rathcoole =========================== ------------------------------------------------------------------------------ o Administrivia chairs 10 min - Blue sheets - Scribe - Agenda bash - Milestones status Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-0.pdf Chairs reviewed agenda -- no comment Chairs reviewed milestones -- PCN WG is behind schedule on our milestones Chairs reviewed consensus calls since IETF 71 (Philadelphia) meeting. There were six questions asked: 1. Should WG produce standards-track scheme with only 2 encoding states? YES 2. Should the WG produce experimental-track schemes that might require another encoding state YES 3. Does the wg have enough info to move forward YES 4. Should routers support the excess-rate marking scheme described by Anna Charny? YES 5. Should routers support the threshhold marking scheme described in the Eardley draft? YES 6. Should the wg consider modifying the interior router excess-rate marking scheme? No consensus. No one made an argument for extending that behavior. Chairs asked question 6 again. There was no support for revisiting this issue. ------------------------------------------------------------------------------ o Discuss ITU-T liaison statement chairs 15 min PCN working group received a liaison statement ITU-T that we need to respond to by 2008-09-01. ITU-T LIaison on Q.PCNApp URL: https://datatracker.ietf.org/liaison/461/ Tom Taylor presented summary slides of the liaison statement. These slides are not a part of the official liaison statement from ITU-T, and are only provided for informative purposes by Tom, who is a participant in the associated ITU-T study group. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-8.pdf The chairs asked for comments from the room. Bob Briscoe: haven't read it, what are we asked to comment about? Steve Blake: comment on any aspect Scott Bradner: document included in Liaison statement, see if it jives In some places, they say wait for PCN. If they are off on a tangent we need to say so. Chairs ask to start a discussion on the mailing list within the next two weeks, so that the working group can formulate a response. ------------------------------------------------------------------------------ o draft-ietf-pcn-architecture-04 Eardley 25 min Philip Eardley presented slides on the PCN architecture draft. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-7.pdf No technical open issues Plan: do a revision ASAP, once the submission tool reopens to clear up a few nits and clarifications that people have raised. Within next couple of weeks. Proposal is that it is ready for WGLC. Changes: Reflect consensus decisions made at Philadelphia or on the mailing list shortly after. Put text re: baseline encoding and experimental extensions Introduction improved Section about backwards compatibility: ECN requirements, doesn't have default ECN behavior (RFC4774) So, Steve, is it ready for last call? Lars Eggert: change, text on probing got moved to appendix. This is one of my all-time favorites. Appendix B on probing. Should it be listed in Appendix A? right now it lists issues for/against. Let's say probing might be something we would do in the future. We don't have a work item to ever do probing right now. Scott Bradner: add text that it might be a future work item. Marcus : optional future TBD of the architecture Jozef Babiarz: can probing be a method for on-path signaling; need to clarify what we mean by probing. Steve Blake: wg has already decided that we are not going to work on probing. Anna Charny: if we are to vote for going to WGLC, is it not better to wait for encoding/marking discussion today? Or do you think no changes will happen? Steve Blake: we will not make decision today, if draft is almost ready (there will be revisions within the next few weeks). Lars Eggert: maybe question should be "assuming no drastic changes..." Steven: Assuming no drastic changes, how many people agree this draft is almost ready for WGLC? 8-9 hands almost ready, 0 against. Chairs strongly encourage Phil to get revision out ASAP. ------------------------------------------------------------------------------ o draft-eardley-pcn-marking-behavior-01 Eardley 25 min Philip Eardley presented slides on the marking behavior draft. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-7.pdf Summary: request that we make this a WG doc rather than individual Steven Blake: How many have read this draft? (lots). Would like to hold off on question until other proposals Jozef Babiarz: this is the only one on marking, others are encoding, we could vote on this now. Ruediger Geib: 2 marking behaviors, excess & threshhold. It does not tell you codepoints, it just describes 2 behaviors. It is ready. Steve Blake: Ok, finish summary, then ask question. Philip Eardley: Basics of doc are clear. Changes from 00 to 01: reflect encoding is going to have a baseline + experimental codepoints. Some changes to traffic conditioning, not very good yet Changes TBD: 1. Traffic conditioning - simplify 2. Purely about PHB, right now it has stuff about edge behavior. Traffic conditioning on interior nodes: simplify section: say things about PCN traffic & non-PCN traffic Per-hop policing (metering/dropping) is not needed. Drop packets if queue overflows, flow termination mechanism to reduce the traffic on PCN interior node. Non-PCN traffic: shares same capacity, might be high priority or same Diffserv priority, might be admission controlled in a non-PCN fashion, might not be admission controlled. "Goal of PCN is to keep PCN traffic within some bandwidth on the link. If you are mixing other traffic, you need to control it somehow outside the scope of PCN" Appendix discusses 2 cases PCN & non-PCN share queue: MUST police non-PCN PCN & non-PCN separate queues: run a scheduler If anyone has any more comments, make them now or on the list? No comments... PHB: Focus on PCN interior nodes PHB. Take out all stuff that's about the whole domain behavior. Goes into a new document that would cover things like traffic conditioning for a whole PCN domain. Marking bahavior MUSTs? Threshhold-marking, excess-traffic marking, have you got 2 or 3 encodings? Should they both be MUSTs to do? silly Should they be MUSTS to implement? Yes, migration easier Should they be a conditional MUST? implementation easier Steve Blake: speaking as chair, interpretation of consensus for MUST implement, means router vendor is compelled to provide both but operator need not turn both on Philip Eardley: so number 2? Steve, group: yes. Jozef Babiarz: why should IETF mandate something that customer does not want? Scott Bradner: IETF has a long history of making mandatory to implement where a fallback for interoperability is required. Want to avoid not having a common mechanism Bob Briscoe: stuck my hand up last time for must implement both. It has been explained that there are situations where you're never going to want both (ex/ enterprise deployments). Rather than conditional MUST, maybe say "if you never want to do it"? Ruediger Geib: IETF avoids situation where ask for PCN RFP: both vendors say they support it, but on closer inspection Lars Eggert: if we want to go with one mandatory, have a hard time choosing Jozef Babiarz: can we split document? Lars Eggert: then we would be doing several documents not just one Jozef Babiarz: Diffserv PHB is an example where we have multiple independent documents Lars Eggert: not codepoints, router behavior. Instantiate different flavors of PCN; if you have to buy new equipment that would be bad for PCN in the marketplace Scott Bradner: one question: how expensive is it to put in both? Jozef Babiarz: not that expensive, requires token bucket Scott Bradner: arguing over a few gates on an ASIC Bob Briscoe: compromise where we say both must be implemented but not both at the same time Anna Charny: only reason where you might want to change consensus is if people thought mandating both would delay deployment. If there is one that is easy, other is not so easy, there might be a tradeoff there. Steve Blake: if we want to revisit this, let's do it on the list. My interpretation of the consensus was that both mandatory. You can't force a vendor to implement one or both of these functions, simply a question of being honest about RFC compliance Scott Bradner: would delay PCN adoption, would delay it if you couldn't predict that one PCN product would interwork with another. Bob Briscoe: configure either one turned on, must support both, maybe that's ok but don't see a need to revisit that. Consensus call: ready for WG document? 12-15 yes, 0 no. Scott Bradner: next time you submit, submit it as a WG document. ------------------------------------------------------------------------------ o draft-moncaster-pcn-baseline-encoding-02 Moncaster 10 min Toby Moncaster presented slides on a proposed PCN baseline encoding. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-1.pdf Based on consensus call that there should be one standard baseline to allow 2 encoding states. Sufficient functionality to make PCN work, allow experiments, minimize use of DSCPs, work within tunneling constraints, allow e2e ECN if possible (would be nice) Current proposal: A DSCP 1: re-use voice admit codepoint, if ready in time ECN codepoints: 00: not PCN 10: not marked 01: not marked 11: marked Marking state: defined within each domain by the operator No distinguish between threshold and excess Intended change for 03: Wasteful to use both codepoints 01 and 10 Change 01 to be Experimental/Local Use Marked state still interpreted locally, ECN still needs to be tunneled Next steps: Revised by end of august. Would like this to become a WG draft. Steve Blake: a couple more drafts on encoding. We can ask, but let's make it non-binding until we hear other proposals. Let's hold off on asking. In conclusion, this baseline draft allows all the proposals, if any experiment proved successful, would just need to update (not replace) this draft. ------------------------------------------------------------------------------ o draft-moncaster-pcn-3-state-encoding-00 Moncaster 10 min Toby Moncaster presented slides on a proposed 3 state encoding. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-2.pdf Basically what was presented at last meeting in Philly Requirements: 3 PCN states Provide support for CL-style admission and termination Minimise use of standards-track DSCPs Optional extension to allow e2e ECN support (must reveal PCN markings as ECN markings to the endpoint, assume that endpoint will do something sensible like reducing vocoder rate). Bob Briscoe: ECN/PCN only one mark will be revealed Toby Moncaster: right, that mark may have been generated by PCN or ECN router Basic proposal 2 DSCPs; DSCP1: likely voice-admit Used effectively same as baseline, now making mark 11 as excess marking Other DSCP2: use 11 for threshold marking Which way around should they be? ECN should be tunneled Extended Proposal Use un-used codepoints to tunnel existing ECN marks through region Use 10 01 on DSCP1 as not marked, use 10 ECT(0) and 01 ECT(1) on DSCP2 Then both ECN and PCN marks revealed to the endpoint. Negotiate that is outside scope of this document. Next Steps Produce as experimental extension Fairly minor modifications to current draft ECN part will be optional Work needed on signalling to negotiate ECN Delay pushing forward until Baseline encoding gets through WGLC Lars Egger: clarification of what would be delayed. Toby Moncaster: 3 state encoding scheme ------------------------------------------------------------------------------ o Multiple PCN Experiments (no draft) Moncaster 10 min Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-3.pdf Why is baseline so good? Can support a huge number of ways to modify PCN, packet-specific dual-marking 3 state encoding 3 state encoding with ECN Tunnel-less CL: if an ISP knows for certain there are no tunnels inside PCN domain, or if equipment has been done ala Bob's way, then you can use the extra codepoints to use for markings LC-PCN Proposal: show all schemes on one slide Basic message: all 5 options preserve semantics of baseline Lars Eggert: are all other ones aiming for experimental? Toby Moncaster: No, just mentioning that baseline doesn't preclude Lars Eggert: documents that describe everything below the first line, none of them claim to go to PS? Toby Moncaster: Right. Steve Blake: standards track with 2 encoding states, experimental with 3. Toby Moncaster(?): Michael Menth has been pushing that PSDM be the base, but that would go against consensus Steve Blake: baseline 11 codepoint indicates packet is marked, doesn't specify excess vs. threshold marked. That's implied by domain operator. Toby Moncaster: Is now a good time to ask for baseline to become WG document? Steve Blake: let's listen to Jozef, then call question. ------------------------------------------------------------------------------ o draft-menth-pcn-psdm-encoding-00.txt Babiarz 10 min Jozef Babiarz presented slides on PCN Encoding for Packet-Specific Dual Marking (PDSM) Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-4.pdf Comparison between this and baseline Similarity: Voice-admit DSCP for PCN traffic One DSCP Use ECN for diff PCN and non-PCN PCN encoding Difference 2 Motivation Lot of scenarios in enterprise, number of aggregates not as high as in carrier backbones, threshold marking has better performance. Want mechanism where we can do admission control, on-path signaling. In 3 SM drafts e.g. RSVP. Provide background on what is meant by probing. Also scenarios where flow termination may be needed. Idea Use exhaustive marking in the network. All PCN traffic metered by threshold marking and excess rate marking Probe packets are subject to exhaustive marking only PCN data packets are subject to excess marking only ECN bits tell routers which packets need to be marked and how ECN bits re-marked from 01 or 10 to 11 PCN Codepoints: redefinition of ECN field 00: not-PCN voice admit traffic not subject to PCN control 10: not excess-marked 10: not exhaustive-marked 11: marked Applicability Supports AC, FT, AC&FT (SM), Probe-based Limitations & Options End-to-end ECN needs to be tunneled Does not support CL style AC & FT when both are used Migrate from single marking to both CL-style AC & FT with a second DSCP Steve Blake: Toby's description of PSDM is not correct? Jozef Babiarz: no, evolution using 2 DSCP encoding is different from what was described in 3 state encoding Tom Taylor: with 2 DSCPs, no more information than with 1 DSCP Could run both schemes in same network Tom Taylor divide data packets into 2 treatments. Steve Blake: How decide which set of traffic should be threshold marked, certain aggregates at ingress (e.g., voice) should be marked somehow, other flows (e.g. video) would be marked the other way. Toby Moncaster: simple evolution is not in draft as present. Not convinced allows CL type behavior. Pre-empted that certain packets can only be threshold marked or excess rate marked. CL requires that you be able to over-write one as another. Then you might end up with 3-state marking. Jozef Babiarz: need to write it up in detail Toby Moncaster: then you don't need extra signaling, DSCP does that for you Bob Briscoe: Of all schemes that Toby put up, could we have some procedural rule that experiments need to describe how to do incremental deployment before can be adopted as WG item. Steve Blake: good idea. mic(?): make baseline compliant, switch DSCP Jozef Babiarz: can do that, this is just another way of migrating. Requires only one DSCP (possibly Voice-Admit) Extension of "baseline encoding" Support two concurrent marking schemes Can we adopt as WG item for experimental encoding? Steve Balke: have 2 questions to ask, that will be one. Q1: Lars, Jozef: e2e ECN should be supported, correct? Nothing in that draft that precludes use of ECN by that behavior aggregate. Lars Eggert: believe you're correct Steve Blake: tunnel scheme for passing ECN marks is to use local-use DSCP, voice-admit at ingress with congestion experienced marked, flip the DSCP carried across network, flip it back on egress. Completely possible to handle ECN with local DSCP? Enough local use codepoints to map them one-to-one? Bob Briscoe: world according to Fred Baker & TSV Area, within access may be many DSCPs, different queues & PHBs. In core they all go together, on egress they all go apart again. If you tried to use diff codepoints would need to preserve this would require too many. Jozef Babiarz: changing codepoints on boundaries, need to change them back on egress. Most vendors/equip providers don't want to do that because it places requirements on vendors Scott Bradner: note that there is no e2e guarantee on DSCP Steve Blake: if we want to re-use voice admit for PCN, or use local use DSCP is kind of arbitrary. Jozef Babiarz: ask TSVWG to specify that voice-admit DSCP does not have default ECN semantics Lars Eggert: don't think it's possible. Can't special-case. Dave Larson working on EF Admit -- ECN desirable Jozef Babiarz: in RFC 3774, that's one method suggested. Codepoint that does not have default ECN semantics applied to it. We can redefine it for PCN. Bob Briscoe: could define diff marking behavior for diff PHB, that's different from saying that there's no behavior Jozef Babiarz: codepoint 00, drop the packet Bob Briscoe: is that better? Jozef Babiarz: implementer, ECN treatment is per 3168. Now PCN comes along and says "now do this". Conflict 2 behaviors apply to one codepoint. Bob Briscoe: for all routers already out there, they can be configured to drop or ?. Default for ECN, RED & Marking, we can configure it to drop but maybe we want to mark rather than drop. mic2(?): useful for emergency, national security deployments ------------------------------------------------------------------------------ o draft-menth-pcn-e2e-encoding-00.txt Babiarz 10 min Jozef Babiarz presented slides on End-to-End Extension for PCN Encoding Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-5.pdf Not part of current charter. Issue: WG define DSCP that can be used for PCN, inside domain or e2e Bob Briscoe: baseline doesn't propose ECN for voice-admit DSCP. It proposes a DSCP of which voice-admit can be one. Motivation for e2e PCN QoS needed e2e, maybe network edge to network edge Need to look at how can do PCN in multiple domains as well as in the future. ECN semantics (RFC 3168) do NOT apply to voice-admit DSCP RFC 4774 defines approach for alternate ECN semantics Request Voice-admit be one of these codepoints Ruediger Geib: what about relying on endpoints to set DSCPs? Jozef Babiarz: In a public network correct, but there are a lot of enterprise networks with devices generally trusted EFadmit draft defines a DSCP value, also describes a PHB and traffic conditioning behaviors. If PCN were to ask for DSCP we would have to do the same. Bob Briscoe: nearly a null PHB. Per-domain behavior. When same PHB being used with a third PHB that is not admission controlled Jozef Babiarz: codepoint has also e2e admission control, EF PHB Bob Briscoe: PCN/ECN marking behavior: PHB is scheduling behavior, then marking behavior is something else. "Marking part" of PHB? We can define that. Steve Blake: do we know which PHB to use for EFadmit? Bob Briscoe: architecture says EF PHB Steve Blake: that is default but not the only one. Q: Should the WG ask for a DSCP to be assigned for PCN? Voice-admit is being defined in another document. Jozef Babiarz: if we want to use voice-admit, we need to speak up now. Otherwise, we will need another DSCP. Lars Eggert: if you want to use voice-admit would be good to have presentation to double-check with TSVWG to make sure our use is ok. Reason for re-use is to reduce DSCP consumption. Encoding schemes attempt to minimize DSCP use. Philip Eardley: Jozef Babiarz: inside a domain, we should have DSCP where RFC 3168 does not apply. Will make interop easier and simpler. Jozef Babiarz: voice-admit ECN semantics 3168, why can't we use EF? Because ECN semantics is per RFC 3168. If we don't we should be able to use any DSCP codepoint, but we can't. Need a different semantics for DSCP Ruediger Geib: use or not to use voice-admit DSCP. Doc stating that should describe from that decision how to treat non-PCN traffic. Measurement based admission control - if use of voice admit would require me to use any other scheme for admission control I'm not interested. Bob Briscoe: couldn't support "at a later time". Jozef Babiarz: suggesting is that we don't stop or delay other draft. In IANA considerations, make statements that 3168 does not apply to this DSCP. In future, another document will define PHB Bob Briscoe: objecting to. Hold packet with TTL of 4 years. Scott Bradner: might get re-transmission Bob Briscoe: have to say drop or 3168 (only PHBs we should have). Can make that choice now. Can't specify another marking behavior because must work for legacy routers. Jozef Babiarz: we are asking for new routers Bob Briscoe: there are routers with EF support, we should not ask for anything new. Lars Eggert: PCN WG can't stick something in the IANA considerations of tsvwg. Very close to being published, almost IESG approved. It is pretty late, need to be quick. Fred Baker will kill you. Doc has been around a long time. Light at the end of the tunnel is near. Jozef Babiarz: we're not all in agreement that we need ECN semantics. Steve Blake: e2e PCN is out of scope Do we need one DSCP codepoint for PCN mechanisms within a diffserv domain? Should it be voice-admit DSCP? Then would need to get it amended post- publication. Can write a 2nd RFC which says to use semantics for this DSCP Bob Briscoe: I thought that's what the marking draft says. Steve Blake: if WG agrees that we need one DSCP codepoint, if we want to use voice admit, write a new document. Bob Briscoe: don't want to agree to one standard codepoint. Steve Blake: Does PCN need only one behavior aggregate in a network? How many people think we could live with one behavior aggregate that gets PCN treatment in a diffserve domain? More than one? Not unanimous, seems like a weak consensus for one. Bob Briscoe: Do we need a diffserv tutorial. Q. Does PCN need more than one queue? One person responds with yes. Lars Eggert: who understands problem we are facing here? Philip Eardley: but do we have the same understanding? Lars Eggert: diffserv tutorial might not be a bad idea. Can make an informed decision. Seems pretty central to what PCN is doing. Small number of people signaling they understand Anna Charny: one aggregate, one queue: different DSCPs can use the same queue. Does it mean that different DSCPs exhibit one behavior? Jozef Babiarz: when you aggregate multiple DSCPs to one queue they get the same PHB. Steve Blake: Behavior aggregate is 1-1 with DSCP values. Different traffic conditioning behaviors but a single scheduling behavior. Bob Briscoe: different e2e behavior, but same in one domain Ruediger Geib: AF 3 codepoints but one scheduling behavior. If you treat it differently in different domains you break that. David Greyson: voice is one application of voice-admit: 2 queues or 2 policers in a single priority queue. Also describes real-time video, would be in more than one queue. Also admission controlled. Can do this for more than one queue. Right direction to apply... asking for another codepoint, now really serious. Have worked with Fred to get it right. PCN on more than one PHB, scheduling Bob Briscoe: Video and audio may have different queues in the access, idea is to put them in same queue in the core. Steve Blake: if we want a standardized DSCP do we want more than one? If only one, would force traffic into one queue. We will craft some questions and test consensus on the list. ------------------------------------------------------------------------------ o Experiment with baseline encoding supporting admission Geib 5 min control and termination (no draft) Ruediger Geib presented slides on an alternative baseline encoding Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-9.pdf Could use baseline encoding, just 2 states, apply marking behavior to indicate two different states of PCN-threshold rate, all traffic marked. PCN-Excess rate, continue to mark most of the traffic, let pass excess traffic un-marked. Allos you to have traffic admission controlled marked, then apply PSDM mechanism of mark Pro/con Benefits: admission control with PSDM, does not require any measurements Termination of admitted PCN traffic based on measured PCN excess rates in egress nodes. Don't need any feedback. Just need one codepoint. Makes MPLS friendly. Drawbacks: Admission control doesn't work properly when above the excess Egress node measure a traffic pattern similar to PCN excess once traffic crosses the PCN thresh rate for short periods only Behavior in the presence of multiple pre-congested PCN nodes is less optimal Anna Charny: when you do submit the draft, explain why it doesn't work. Ruediger Geib: set up an experiment. Steve Blake: 2 questions:/ Q1: How many people think we should adopt draft-moncaster-pcn-baseline-encoding-02 as WG document? 12 yes, 0 no. Q2: How many people think we should adopt draft-menth-pcn-psdm-encoding-00 as a WG document intended for experimental track? 4 yes, 0 no. Not consensus. We will confirm it on the list. Philip Eardly: baseline make a bit more progress before having one or more of the experimental drafts made WG documents. Bob Briscoe: is there any harm in making things WG docs that don't eventually become RFCS? Scott Bradner: as long as it's in charter. If it's not in charter or not making a contribution then it shouldn't be. Bob Briscoe: encoding extension that Toby describes could be a WG document. Jozef Babiarz: is the consensus that we wait, before introducing alternate or experimental encodings? Steve Blake: Should experimental-track drafts become WG documents? 6 yes, 2 suggest waiting until the standards track documents progress ------------------------------------------------------------------------------ o draft-briscoe-tsvwg-ecn-tunnel-01 Briscoe 10 min Bob Briscoe presented slides on Layered Encapsulation of Congestion Notification Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-6.pdf Should be a WG item in the TSVWG, trying to get support. original authors of 3168 support this, there was support about a year ago but was asked to wait until PCN got a bit further. Background on problems we are having with encoding/tunneling. Update to RFC3168: Proposed change: remove one type of behavior that is unneceessary Limited functionality vs. Full Functionality NG IPSec, RFC 4301: Just copy inner header to outer header Copy creates covert channel, but security area doesn't care. This draft removes full functionality column from table. Excess rate markings won't work well with multiple bottlenecks. Over-terminate flows. Steve Blake: on egress of tunnel, behavior is? In an appendix: relationship between ECN and in-band admission control, tunneling For the egress, behavior doesn't change much, just a clarification on one invalid transition. Can't use some bits in outer header for PCN, they will be thrown away. Jozef Babiarz: switching ECT(1) & ECT(0) will it break e2e nonce? Bob Briscoe: no, it is currently broken and this fixes it. Draft says make everything like IPsec, changing the behavior of an IPSec node. IPSec currently does it the other way around. Jozef Babiarz: IPsec doesn't flip the ECT bits, how does that break the nonce? Bob Briscoe: doesn't break e2e nonce, means that a router in the tunnel removes a congestion-experienced that another router put on, can't detech routers that have removed congestion-experiences, which is one of the problems Lars Eggert: update RFC 4301? Only way to affect IPsec is to update 4301. Bob Briscoe: at the moment the draft doesn't update 4301, this is just in an appendix, just a discussion not normative or anything like that. What do you think my chances are to allow this update? Lars Eggert: chance of asking is pretty high. ------------------------------------------------------------------------------ o draft-westberg-pcn-load-control-04.txt Mekkes 15 min Hein Mekkes presented slides on Load Control PCN Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-10.pdf Main updates from previous draft -03: Supports both trunk and hose model Sliding window is moved to the egress When PCN_Affected_Marking is used, then flow termination is triggered at the egress Calculation of configured termination rate has changed Used to decide how much bandwidth has to be terminated. If PCN_Marked rate * N > link bandwith, ctre = (U-1)*total_load If PCN_Marked_rate Description of flow termination experiments included. Admission control experiments not performed since functionality is identical to Single Marking admission control functionality. Trunk (IE-aggregate) and HOST-model used In draft no results shown, but they are shown in this presentation Experiments: simulation. 2 different topologies. One with a single bottleneck, other with 5 bottlenecks (parking lot topology) Intended to do CBR and VBR, but unable to do VBR experiments Metrics: Over-termination Reaction time Duration of time that a bottleneck node remains in flow termination state Simulation parameters Description of experiments Topologies, number of flows, Over-termination percentages SingleMarking LCPCN-trunk LCPCN-host Handling times vs #ingresses Graph Experiment 2 parking lot topology Over-termination percentages Philip Eardley: previous slide, is there a significant difference between these? What's the range over which they covered? How big is a single point? What is confidence interval? Hein Mekkes: only one point. Reaction time is about 200 ms for each congested link. Conclusions and next steps Leave open the option to use random dropping of marked and unmarked packets in interior nodes Leave open the option to use PCN_Affected_Marking encoding since it can solve the ECMP problem and provide an efficient solution for the HOSE model. Leave open the option using the constant N such that the marked excess rate can represent also high levels of measured excess rate Philip Eardley: 1st and 3rd contradict consensus in Philadelphia Hein Mekkes: didn't know that, wasn't there. Philip Eardley: marking draft presented says excess traffic meter function SHOULD preferential dropping of packets which are excess traffic marked. Random dropping contradicts that should statement. On the effective marking: covered by experimental encoding as presented by Toby Third one contradicts consensus we reached in Philadelphia. Steve Blake: any support for revisiting the question? No support given Steve Blake: We will stick with previous consensus. Meeting adjourned.