CONEX BoF, Session 1 March 24, 2010 15h10-16h10 Chairs: Leslie Daigle & Philip Eardley Jabber Scribe: Ted Hardie Note takers: John Leslie, Matt Zekauskas Leslie reviews what's been happening: BarBoF Stockholm, GIIC workshop, BoF in Hiroshima; two key questions there: "is conex a problem" YES; "is there IETF work here" YES. Followed up with draft charter, which provoked IESG comments; hence this BoF: why Congestion Exposure, response to IESG comments; need clarity, charter outline; looking for clarity in charter text; agenda for tomorrow will be posted after today. Want to clarify: there are 3 pieces: (1) generative technology, (2) deployable uses, (3) one implementation, re-ECN, (basis for believing this is worth pursuing); hard to keep these three separate; want to focus on first today. From the slides: congestion exposure is "A mechanism by which IP datagrams can signal the total rest-of-path congestion that they are expecting along the entire path they are traversing." Three presentations Presentation: Mat Ford, Some data from ISOC panel in IETF76 Briefing paper published yesterday Access networks getting faster; pressure from broadband, etc. Data of Japanese market, over four years Internet Observatory: private peering bringing content "closer" Pinch Points: CPE (typically no AQM), aggregation routers, interconnects Impact of individual subscribers increases; additional capacity may not be cost-effective; tools limited Questions? Hannes Tschofenig: also MIT project to run similar analysis, should be available in a few months David McDyson: is it in-charter to look at incentives to balance? Presentation: Richard Woundy, ISP perspective Three areas of concerns: customers & activities, external third parties, our own network; impact on customers is key -- customers calling -- do we know why there's congestion? Regulators are asking us what effect on customers & how do customers learn of issues Fixing congestion tends to require truck-runs -- may be delayed by weather, etc. Demand may double by the time you fix problem We want low-volume traffic not disturbed by high-volume uses; we want customers to be able to prioritize their uses Potential Use Cases: input to congestion mgmt; discovery/diagnosis of issues; possible DDoS mitigation; incent LEDBAT-like applications; congestion can occur in many places; customers report trouble on social-neworking sites and blogs (example where diagnosis was particularly difficult "Why don't you get back to me when you have something deployed" -- understandable Two "ecosystems": implementation ecosystem, network-deployment ecosystem -- engineering issues, not research issues Phil: use cases later, but use cases not in scope yet Hannes: valuable insight from Rich's presentation of Comcast's experiences, wish other providers would give similar info; what can be done today with existing tools; interesting properties, e.g. protocol-agnostic Presentation: Alissa Cooper -- Traffic Management tools & techniques Reasons why providers do traffic management Easier to deploy, cheaper than expanding, build-out schedules, fine-grained control Throwing capacity at it: straightforward, meets demand; but expensive, can't solve congestion on other networks, spreads cost to those who don't need more capacity Approaches: volume, rate, applications; what metric to take action, what action to take Volume caps, volume penalties; but impact too restrictive in times of low traffic, insufficient in times of very high volume Rate-limit, simple to implement; but too-much/too-little restriction Application-based: sensitive to use characteristics; but cat & mouse, public-policy issues Combinations... Benefits of Congestion Exposure Incentivizes reduced-congestion protocols like LEDBAT; Exposes congestion end-to-end, across network borders; transparency at every network node (good for capacity planning); enables Internet-wide solutions David McDysan: seems more access-network applications; focus on use-cases including access networks and transit networks, wireless access networks, collect/distill to prioritize requirements Leslie: good point. Is everyone clear on what problem is and the scope of impact.? silence... Leslie: Everyone seems to be clear on the scope, based on the "silence is agreement" model. Phil projects slide with Framework of charter Leslie: Now on to the Charter text discussion. Not all will get discussed today, but the meeting tomorrow will pick up where we leave off today -- please be sure to come back tomorrow as well. Phil: slide "the generative technologies" -- the major work item (in v4 and v6); how to carry congestion information Manesh ?? (microsoft): seems to be wired-network specific, need more input from wireless operators Phil: that wasn't on slide Matt Mathias: worth doing the exercise of some "test marketing" -- take this paragraph to people that haven't read it before, watch them read it ask if know what means. It would help to ask such folks to explain what they think it says Leslie: to a large degree this session's primary purpose is to clarify this text so it reflects what we agree are the tractable work items for a WG. Hannes: would be good to involve cellular operators in this discussion; problems & resolutions are different. Ingemar Johansson: Plan to submit a document on wireless aspects Lars: a little disappointed, one reason why approved second bof was because we had strong consensus, but IESG issues. Would have liked to see more people wearing dots to understand if issues resolved or not. Hoped to clarify the issues, would have been best to hear issues today and come back tomorrow for answers; I wonder if this has helped at all Adrian Farrell (IESG member): didn't find this helpful for issues which came up; difficult to grok, "given my previous experience this is my expectation of what congestion I may see in the future". Once had parsed that, he was able to understand where the group was going, but he is still not convinced that there is demand for it. He is cautious about burning cycles on items that might not get traction. Leslie: Happy to address the detailed comments once the core question of whether this IETF or IRTF work; she had hoped that the presentations today would address that. Andrew McLaughlin: I don't understand how we're going to deploy this among service providers. Appreciation expressed for Adrian stepping up to the microphone -- others voiced private concerns, Adrian helped by voicing publically. Lars: good place to stop; you can corner Adrian before tomorrow. David Harrington: I had some concerns about how this is to be used between providers, specifically the incentive to cheat THURSDAY, March 25, 2010 1510-1610 Afternoon Session II California B TSV conex Congestion Exposure BOF Chairs: Phil Eardley, Leslie Daigle Phil Eardley (PE) presents slides: http://www.ietf.org/proceedings/10mar/slides/conex-4.pdf Gorry Fairhurst (GF) - You're talking about experimental modifications to IPv4 headers yes? PE - Yes. GF - Re-writing Proposed Standards and obsoleting them or updating them or what? Does the experimentation invalidate anything which is currently in PS or does it just use reserved bits? PE - I believe it does not GF - Does it invalidate anything which is currently experimental? Bob Briscoe (BB) - If we're talking about re-ECN, you would have to update RFC791 to say that the last bit is no longer reserved but experimental. And then you'd have to write an Experimental RFC to use it. That process was used for ECN. The only other thing is ECN-nonce which is Experimental currently. We would have to work out a way to set that aside while we do this experiment. GF - That was nicely worded. Dave McDysan (DM) - In IPv6 we would have more degrees of freedom, potentially more capabilities in IPv6 using more bits. Ingemar Johansson (IJ) - This work should be standards-track. PE - We've already had strong feedback that work items should be Experimental rather than Standards Track. Leslie Daigle (LD) - It's not a broken path to start with Experimental and then move to Standards Track if experiment is successful. There is consensus that the desired outcome is a standard. Georgios Karagiannis (GK) - There are only two major work items - are others to follow? PE - Yes, see later slides. GK - When these bits are signalled across the network, the network has to do something with them - where is behaviour of the network specified? PE - See later slides. David Black (DB) - ECN was experimental for a time before it went to standards track. Matt Mathis (MM) - There is another strategy here - talk about an abstract implementation and how functional units might work, and then map to a coding which forces you to give up some of the functions. LD - We'll touch on that later in this talk. IJ - Concept of conex is good. If it had been proposed 20 years ago would resistance have been higher or lower? PE - We could discuss that over beer later. Tim Shepard (TS) - I'm a fan of this technology, but my hope is that 20 years from now it might be extensively deployed. I doubt we're going to see this inside of 10 years. But it's important to do the work now - if we don't it won't be here inside of 20 years. LD - We're trying to unlatch requirement that says we have all the final answers and rather say lets get the work started - going for EXP acknowledges that we don't have all the right answers. DM - I and others in my company have concerns about retrofitting this to IPv4 - should really be focussing this on IPv6. PE - So you're happy with delivery, it's just about the process of getting there? DM - Supports MM comment, there is another deliverable (abstract design) and the order is generic requirements and then that drives how you do the encodings. Andrew McLachlan (AM) - If we're still counting congestion in 20 years then we've done something seriously wrong. Bandwidth is getting cheaper and cheaper and if we're still using congestion to measure congestion we've made a huge mistake somewhere along the line. LD - Not agreeing with that point we need to move on and not argue it because if we argue it we'll be done with today's session. PE continues with presentation PE - Are people OK with this narrowed Charter? MM - If this makes it easier to get past the IESG, then we should do it - we can always change the charter later. PE - Are there any ADs in the room? LD - The only question should be 'is this well-framed work for the IETF'? John Leslie (JL) - I have no problem in principal with narrowing the charter, but I don't understand why this narrowing would make anyone happier, nor does it look like a good way to define a generative technology. LD - Instead of trying to map out the entire path, this is what we do know today. This is the work that needs to get done in order to get the work started, and the use cases are the biggest unknowns, so moving them out seems like a non-lossy way to proceed. Ross Callon (RC) - Former AD - personal opinion having heard other ADs discuss this is: this is interesting research that we don't think is going to get deployed in the Internet - unless we hear from a lot of service providers that they want to deploy. If narrowing the scope of the charter makes it clearer how we'll get this deployed then that is a good thing. BB - Supports going for experimental status. It is very difficult for people to imagine what they might do with this until it exists. An experimental protocol that allows you to build a testbed and start using it allows people to understand what it is for. We're trying to prevent what happened with NATs happening with DPI (i.e. nothing is specified and we end up with a mess). Rolf Winter (RW) - We have heard from operators that this is an important direction and they need a standardised solution. If we don't work on this now then we don't get to complain in 10 years when DPI is pervasive and breaking the network. Jason Livingood (JL2) - Bob's last point was a good one - similar to NATs, if there's not something standardised in this space then you will see a lot of proprietary DPI devices deployed and that is a risk. JL - I really don't even understand how you're proposing to narrow the charter. LD - We are here to review the proposal to reduce the scope. JL - I have no objection to a reduced charter. RW - The narrowed scope addresses the problems raised, and leaves the core that we want to work on. Once we have made this initial piece work, there are probably additional things that will follow. Ken Carlberg (KC) - Will IESG express their concerns publicly? Could they please be encouraged to do so? LD - Yes, shadowboxing the IESG isn't fun. DM - Will the charter be revised as MM proposed? IPv6 deployment could be enhanced if we focus there. LD - Is your concern that we not focus exclusively on IPv4? DM - Yes MM - Coding for IPv4 is harder, so abstract design followed by coding work could help. MM - Re future-historic tense - better sense: 'to allow all the elements along the path to get information about congestion all along the path' Chris Morrow (CM) - We could do better with existing tools. I'm not sure I see a need for this. LD - Were you in the room yesterday? CM - No LD - Check out the materials and minutes - the problem statement was extensively addressed. CM - OK. Adrian Farrell (AF) - I've caught every second word - had to be in another room. Experimental proposal gels with how I feel. I'm a little nervous about the use of the very last bit in IPv4, maybe we could cut it in half :) . An option might be to work on this in IPv6 first - if it flies there I might feel better about allocating the last IPv4 bit. PE reviews proposed narrowing of use cases. AF - was there any discussion about what the level of demand for this is? LD presents Bob's analysis of support gleaned from the mailing list. Stewart Bryant (SB) - Glad to see moving this to an Experiment, encourages focussing on IPv6 - glad to see narrowed scope so that it can work with MPLS, nervous about interaction with white cloud in the diagram. Can white cloud inject information that causes mis-allocation of funds? Ted Hardie (TH) - clarifying question - are you asking that the charter do something to address this, or are you asking whether re-ecn addresses this? How re-ecn deals with this now is not relevant. SB - Charter should clearly address the security risks. BB - on the v4 vs. v6 topic - a number of people have thought long and hard about using up the last bit of the IPv4 header - difficulty is that sensible trials with real users and real applications need real traffic (don't mean to be rude about IPv6, but we won't get that there). IPv4 code can be restricted in time and space. AM - As a provider, why would I want to express that my network is congested? The use case should take that into account. TS - Would your question apply to ECN? AM - I'm not well-versed in the protocol. MM - If you don't mark then remote senders will hit your network harder because you're effectively giving them permission to use a higher data rate, this signalling is how we tell senders to slow down. AM - the use case needs to express this. TS - It would be a burden if the experiment had to be conducted on a v6 only network. It needs to be considered whether that burden needs to be put on this work. LD - We need to balance need to have a runnable experiment versus concerns about burning the last bit in the IPv4 header. DM - IPv6 networks as they're being deployed are smaller in scope, more experimental, more likely to experience congestion. If an experiment there can show a benefit versus IPv4 network that's a more experimental environment for operational traffic for operations folks at Verizon. Mat Ford (MF) - It's hard to understand why people have difficulty with the idea of re-classifying the last bit in the IPv4 header to allow experimental use, when it is debatable whether IPv4 has a long life-time ahead of it. LD - Perhaps another way of expressing that is to ask, do we reasonably project that in whatever lifetime IPv4 has there will be cause for a standards-based use of that last bit? Lars Eggert (LE) - One proposal would be to initially limit experimentation under the initial conex charter to IPv6. We need to investigate how experimentation in IPv4 could proceed and be limited as necessary - make this a work item for conex. If that proves positive reconsider the limitation and potentially re-charter at that point. LD - Certainly don't want to gate chartering conex on this point. LE - It's clear that it should be possible to get useful data from IPv6 experiments. Mark Handley (MH) - We need to define how we know whether the experiment has succeeded or failed. The bit has to be redefined as experimental for anyone to make any use of it for anything, otherwise it's just a useless bit. LD - Thanks all for your input. Revised charter will appear on the list in due course. ENDS