Congestion Exposure (conex) WG meeting, IETF79 THURSDAY, November 11, 2010 0900-1130 Morning Session I Valley Ballroom B Notes by Mat Ford, ford@isoc.org ably assisted by Leslie Daigle Agenda bashing, scribes Agenda: http://www.ietf.org/proceedings/79/agenda/conex.txt ----------------------- No bashing ConEx Concepts and Abstract Mechanism draft-mathis-conex-abstract-mech-00 Bob Briscoe, 15 min Slides: http://www.ietf.org/proceedings/79/slides/conex-5.ppt ------------------------------------- Andrea Soppera (AS) presents on Bob Briscoe's (BB) behalf Ingemar Johansson (IJ) - regarding loss-based audit - conex will not be deployed in a couple of years, so end-points will be updated to support conex and ECN at the same time, there will be other boxes in the network too - how likely is it that in future you won't have ECN support? 5 years from now the situation may be very different. Marcelo Bagnulo (MB) - you can't know. so the question is whether we should place a bet here, and link fates to ECN deployment, or do something more complex. if ECN is deployed, can we remove this complexity? I don't know the answer, but it would be wise if we could remove it. Mirja Kuehlewind (MK) - can't ignore loss as a congestion signal Rich Woundy (RW) - signalling in IPv6 but not in IPv4 may make situation more complex as well. Adopt as WG item? MB - not asking about sending to IESG, just asking about adoption - do people have comments? Dave McDysan (DM) - charter related question - first result is usage scenarios document - other docs will not see publication until that is done - have already had questions on list about additional use cases. if we adopt this as the mechanism document then we foreclose use-case discussion. there are use cases being elaborated that aren't supported by the mechanism, so we could be going round in circles here. MB - are you envisioning additional use cases that could not be satisfied by this mechanism? DM - yes MB - is this a little different or a lot? DM - could be a lot different. this is a good approach for short timescales, but could do something longer term, slow path. MB - so you would like to agree use cases? Leslie Daigle (LD) - i would like to support adopting mechanism document. just don't use it as a blunt instrument to bludgeon people proposing new use cases. MB - would that work for DM? DM - yes, if that decision can be documented. MB - yes, it will be documented, I will remember. RW - agree with LD, adopting this would break the logjam. appendix of moncaster use cases draft could move into this draft. then other use cases could build on that. MB - easier to do that when docs are WG docs. once WG status is agreed, then we are obliged to make them coherent. MB - given this discussion it seems asking the question is appropriate. who thinks we should adopt? many. who thinks we should not adopt? none. OK we're done. ConEx Use cases draft-moncaster-conex-concepts-uses Rich Woundy, 15 min Slides: http://www.ietf.org/proceedings/79/slides/conex-0.pdf ----------------------------------- Ken Carlberg (KC) - draft doesn't reflect latest discussion on the list, right? RW - right. we think we'll drop DDoS use case, but we want to verify that here. Alissa Cooper (AC) - is one of these the accountability use case? RW - accountability is in the draft, don't know why it's not on the slide - an oversight. we don't expect to drop that. accountability use case - says that if everything is conex enabled... MK - the point is that you have the conex information at the network ingress, rather than estimating. can make sender accountable. RW - i guess i thought that was included in these, but i agree. but we haven't dropped it. MB - Questions for the WG - How to manage the remaining ConEx mechanism material? DM - no objection, but I made comments to the chairs about separation of use cases and mechanism. need to do this work, need to have a starting point. DDoS use case ------------- RW - Objections have been raised to keeping DDoS as a use case. Is this just so far out it should be entirely dropped, or can we get consensus from WG on how to explain this better? Impression from last meeting was that people feel DDoS is handled some other way, but reticence about describing how is troubling because simply saying DPI can deal with this isn't really the point. DM - compromise could be that instead of current text could state that it would be desirable to do something with conex to address DDoS - placeholder could help us move ahead. This needs more discussion. RW - Another variation would be to remove it now, adopt as WG item, then we can add it back in later if the WG later comes to consensus on the right way to do that. DM - Yes, that works. IJ - I'm not a DDoS expert, but i believe conex could be used as a component in DDoS mitigation. RW - So this is an interesting use case to you? IJ - Yes. RW - Even if we end up dropping this, it's useful to think of this as the worst case scenario of someone trying to actively work against congestion control and congestion exposure. How to clarify differential QoS use case? Keep this, but needs severe wordsmithing. What use cases should be added? Save this discussion for after DM has presented. Are there another set of hidden use cases that we need to discuss right now? MB - I don't know of anything other than DM's work. But this is an open question and will remain so until we finish this deliverable. MB - After Maastricht I think we had agreement that this document should remove mechanism description and DDoS use case. Is WG OK to adopt as WG item assuming Section 5.3 and Appendix A are removed? If we adopt this document, I expect authors will resubmit without those two sections. This doesn't mean we will never work on DDoS, but we're not ready to do that now. How many for adopting this draft (without ยง5.3 and App. A)? Many How many for not adopting? None Alissa Cooper - channeling Bob Briscoe from jabberland - I didn't think we were asked to remove the DDoS use case, just to tone it down. MB - I am asking to remove it. That is what we just agreed to do. MB - authors - please resubmit without those two sections. ConEx Use cases draft-mcdysan-conex-other-usecases-00.txt Slides: http://www.ietf.org/proceedings/79/slides/conex-1.ppt ----------------------------------------- Inequity of heavy versus light users ------------------------------------ RW - I understand the 16x number for congestion volume. If 20% of users are generating 80% of the traffic and 80% of the users are generating 20% of the traffic, then if you do the math its 16x. It's an interesting question whether the 20% of users that are generating 80% of the traffic averaged over 24hrs are the same 20% of users generating 80% of traffic during peak. My gut feel is that they're different. Light users aren't using it at 3 o'clock in the morning like the heavy users are. Light users are using it during primetime, so their overall traffic share is higher during peak time than non-peak time. So how appropriate is this really? DM - I agree. It's the peak period time where the provider incurs the cost. It really only matters in the months leading up to provisioning new capacity. Al Morton - Rich, it's important to keep in mind you can be a very unsophisticated user and still cause a lot of volume. DM - John Leslie had a number of comments and if this were to be adopted we'd want to answer those. MB - Do we include this in our use case document or not? MK - Is this anything more than measuring congestion over some period of time? That's what conex provides you. So I'm not sure what you want to do with this information. DM - Point is that this is over a longer period of time. Not about inserting every packet. Some mechanisms described in later presentation from ericsson (IPv6 Format) could be used for example. MB - (chair hat off) - in other use case you have incentivising better Congestion Control and traffic management, is this somehow different? what's the goal? DM - so those are specific mechanisms. what is being proposed here is a different measure than is proposed in the use case draft. this is a longer term measurement. most of the things i'm proposing here i think can be done in software, which may be more appropriate for an experimental group interested in incremental deployment. i think this is similar to what's called 'flat rate' in the current draft. AC - maybe i was trying to read something into this that isn't there, but i'll try to articulate. i think you're talking about an extension of the way the abstract mechanism is currently defined, and then you're creating some use cases out of that. it's not explicit in the currently adopted use case draft that traffic management use case and settlements use case is talking about a short timescale. could be valuable to add discussion of what more you could do with longer timescales. DM - i'd like to look at the use case, and not force a specific mechanism. trying to fit everything into a bit-compressed set of states is something i'd like to avoid. seems like an unnecessarily restrictive decision. MB - what i understood AC saying is to include in the current use-case document discussion of different timescales. would that address your concern? AC - exactly MB - would that cover your concern? DM - yes MB - i think we may want to do that RW - are we deciding adoption of these individually, or at the end? MB - i was thinking we discuss each one in turn. we know we are not adopting this as a document. RW - so we agreed that we're going to include a use case that talks about using conex to account for inequity of usage over long timeframes? MB - yes BB (from jabber) - conex information is designed to be the best way to measure when burstiness matters - it works over multiple timescales by design - will need to explain this on the list MB - so we need to make this explicit, which is what you (AC) already said DM - usage tier/volume feedback slide MK - i think this is valid, but i think having an interface to expose accounting information to the end user is out of scope for conex at this point. you're proposing an additional interface right? DM - i'm proposing it as a service where you use conex information to derive tier information which you feed forward to the user. actual billing is out of scope, but counting is in scope. charter is somewhat ambiguous on whether using counting for billing is in or out of scope. this is an important question for the WG. MK - you're proposing an additional mechanism, so it's out of scope. let's first do conex, then worry about stuff on top of that. RW - last bullet says 'conex feedback could contain an authenticated pointer to a lot of information'. expectation is that conex feedback will be at IP level, so not clear how this could be done. i think favourably of this, i'm not sure if it's in scope, but i do wish we had this. in the USA right now, in the FCC, there's a lot of concern about wireless bill shock. i don't think that investigation is about whether there should be charging for volume, but a $17,000 bill is a problem. it might be interesting to capture this as part of your use case. DM - thanks for sharing that motivation, i didn't include this in the draft as I didn't want to be too parochial. on the authenticated pointer question, you may not carry the information, you may have a token that gives you the URI. IJ - security issues are severe here - one must be cautious that this isn't burdening the abstract mechanism MB - this could be a hint, right? this is hint information about where you are. IJ - i can agree, but we don't want to end up with a monster. MB - I agree with MK, this is one thing you can build on top of conex. given the problems we had chartering this work, i would rather be much more cautious at this point. this is a bit of a stretch. i don't have a problem with the idea, but i'm concerned this may cause us trouble. DM - several have raised scoping concerns. this could get large quickly to do this right. MK - can keep this as an individual draft, and could be added later as people seem to be interested. DM - that's a good suggestion. since it appears there's interest maybe we fork this one off to an individual draft. if it gets more interest we can add it back in later. next proposed use case - feedback on time of day, day of week charging Mat Ford (MF) - this is good, is it same as incentivising better Congestion Control but with focus on benefit for ISPs as opposed to end users? DM - pricing is also a benefit for end-users MB - (chair hat off) - i would like to include ISP perspective in use case that we already have, but i'm not comfortable including explicit pricing related discussion in our document. RW - when i think about incentivising ledbat, then either ledbat session is happening 24hrs a day. for apps not running 24hrs a day, this could incentivise users to change their behaviour, so not related to Congestion Control algorithms. (discussion here that wasn't captured because I was involved in it) MB - there's too much debate on this to know what to do with this one at this point Recharging for implementing congestion pricing ? Ericsson - we have tried this for 100 years and it still doesn't function. customers don't want to pay a lot for sophisticated billing mechs. we're trying to get away from dynamic billing. RW - as author of other draft, can we quickly send consensus of various use cases to the list so we get all of this straight. MB - let's discuss this offline. DM - last slide Richard Yang - conex very interesting mech, but could be dangerous toy. could be useful to define non-use-cases in addition to use cases. ConEx IPv6 format Suresh, 20 min Slides: http://www.ietf.org/proceedings/79/slides/conex-2.ppt ----------------- MB - packet processing will be out there, so you mean routers that are on the path that are not aware? Suresh Krishnan (SK) - Ken Carlberg - for R2 does that imply probing to find out if there is a problem on the path? SK - no. the idea is to be opaque to those that don't understand. i'm assuming passthrough is a requirement KC - probing is to find out if there's a black hole. SK - right, so i have 3 candidate solutions, one has probing characteristics, others don't - they work around breakage. MB - you can think about virtual extension header - steal some bits from the extension header - you don't need the header itself SK - right but other issues still hold MB - yes MB - hop-by-hop options, there is a router alert option - would that be proper fit here? i hear horror stories about router alert option SK - router alert option is a hop-by-hop option, special case. other hop-by-hop options are e.g. jumbogram MB - so you think it would be better to use a different option than router alert SK - router alert is evil RW - you talk about slow-path vs. fast-path - that's not always operator choice, sometimes vendor choice. so i totally agree - we need to ensure that traffic isn't all punted to slow path or we'll never see deployment. MB - we're chartered to do an experiment. how important is this consideration in this context? RW - taking that into account, i'm still worried about slow-path. [gives example] slow-path is so significantly less performant that it can cause other problems rendering the experiment redundant. BB - if a new hop by hop has a bit set it means SK - it always gets punted to the slowpath ? - slow path is 100,000 times slower than fast path Lars Eggert (LE) - can use hop-by-hop for lab testbed, but to take this to operators we need a final encoding that doesn't involve hop-by-hop. MF - if flow label is experimental, can we use it for an experiment? SK - no, you MUST NOT assume structure LE - yes that' right. we can change IPv6, but it will require a very wide consensus. Tim Sheppard (TS) - I saw discussion in 6man, property that we won't get consensus on, is that if src sends packet with non-zero flow label, it's immutable end-to-end. i don't think asking for mutability will fly. SK - absolutely right, but nobody said flow label had to be 20 bits. it's not being used, so let's use it for something constructive. ? Ericsson - you say passthrough is not acceptable, change of header bits is as big an obstacle. SK - only sender sets flow label, intermediate nodes do not touch it. Andrew Macgregor (AM) - if you're talking about changing the flow label, you're talking about patching the fast path. this is implemented in silicon. ? - maybe products will arise clearing or doing something non-compliant with flow label. SK - what's your view? ? - use the flowlabel BB - mask the last four bits SK - nothing is acceptable in 6man, it's an uphill battle. MB - we need to wrap this up SK - last slide MB - maybe we can organise an interim meeting to figure this out, because we need to react here. ConEx TCP modifications Mirja, 15 min Slides: http://www.ietf.org/proceedings/79/slides/conex-3.pdf ----------------------- No draft yet, but wanted to discuss some points that have already been presented. MK -- should there be consideration of the case where the sender does not ask for ECN (i.e., relies on dropped packets), eg for low power devices DM -- this is experimental -- should not make this dependent on ECN, might make it hard to retract if experiment ends and codepoints reassigned TS - are you proposing we carry this in a TCP option? DM - yes MB - see multipath TCP AM - he was only looking at options, not the NS bit MK - will raise most of the questions again on the list and they can be discussed in more detail there. Auditing ConEx signals: Handling inherent feedback delay. Background I-D: This talk accompanies #1, but goes deeper into one aspect that the w-g needs to debate and reach consensus on: how to allow for the min 1RTT delay between an actual congestion signal and a ConEx re-echo of that signal. Specifically for the function checking for cheating (we decided to call this the audit function). The talk will argue that the transport, not the network, should be responsible for allowing for this delay, which justifies an additional Credit codepoint (aka Green) in the wire protocol. Bob Briscoe, 20mins Slides: http://www.ietf.org/proceedings/79/slides/conex-6.pptx Andrea Soppera (AS) presents, apologies from BB IJ - is credit used in policing function? AS - could be used in policing function IJ - maybe this is implementation details AS - when you initiate a flow you declare the congestion you expect to cause, could deplete allowance in the policer function, so yes, you should use this in the policer function. MB - Out of time for final presentation. MB - We expect to hold a virtual interim meeting before Prague. Meeting ends.