-------------------------------------------------------------- CONEX WG Meeting Minutes IETF-84 meeting @Vancouver -------------------------------------------------------------- 1. Congestion Exposure (ConEx) Concepts and Abstract Mechanism https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/ M. Mathis, B. Briscoe Matt: next step: tsvdir review. Marcelo: What's the approach for the security mechanism? Matt: We did this doc -- didn't understand how coding would affect applicability, afraid problem already over constrained; point was to have a basis for analysis of tradeoffs, but is not a complete spec. Marcelo: Next question, what about the "not done" audit document? we need some rationale to get to work. Nandita: Should the audit details be in abstract-mech, or in a separate doc? Matt: Intend to write as if section in another document. Mirja: if we have all the requirements in the abstract-mech, could this section change the requirements? Matt: Very subtle design decision: is statistical marking allowed? Is low-grade cheating allowed? That would potentially change the requirements. But this is very subtle, and the only one I've noticed. Mirja: would like a section describing the problem the document would be intended to solve. Matt: okay. Wes: if everyone agrees that this effort will not hold up abstract-mech, then we're in good shape. Mirja: we need a document describing design decisions, since if you only have one algorithm it's easier to cheat. Marcelo: I'm not happy with security by obscurity. Matt: variants of mechanism to illustrate: deterministic algorithm keeps red, black, and green marks all the way back to the start of the flow. statistical audit starts in the middle, makes sure long term red-black balance is black. These catch different kinds of cheaters. We need to write this down someplace. Dirk: the right approach: say you need audit, list the threats, document describes specific instantiations. Marcelo: We can have this document, even though it's not in the charter. Who's going to write it? Matt: Read Bob Briscoe's thesis, and rewrite it in IETF language. Bob? Bob: Have already done thesis. Don't want to do it again. What about security people? Marcelo: Would rather someone in this room. If you're interested in doing this, please let us know. Nandita: Matt, since you already outlined the two schemes... Matt: Will review my notes and consider sending it out. Can provide list of questions it needs to answer. 2. TCP modifications for Congestion Exposure http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-02 M. Kuehlewind, R. Scheffenegger Mirja: Open issue #1: What if conex markings get lost? Retransmit, heuristic marking retransmit, audit should not account drops it caused. Do we need more recommendation, or should there be further experimentation? Personal opinion: don't address more than necessary, leave open for experiments. Nandita: that's my sense too Mirja: Open issue #2: How to avoid sending credits instead of markings or vice versa? Are there other ideas for incentivizing senders? Suresh: What if I don't put the conex option in the header. would audit catch that? Matt: The assumption is that non-conex traffic is subjected to different QoS. Want to treat non-conex marked from conex without sending credits. Jabber question [unknown name]: [unintelligible] section is hard to understand. Mirja: Will rewrite this section, add information. Marcelo: Is this related to the new audit document? Trying to understand whether we're stuck on that document. Mirja: right now recommendation is send credits only in slow-start. question: is this right? problem: short flows incented not to mark. Nandita: Does not appear tied to audit document. That can go into details and questions. Mirja: Not sure if there is additional text needed with respect to audit. Marcelo: What's the plan? Mirja: Will finish TODOs, one more revision, and wait on reviews. Marcelo: After that revision, WGLC? Mirja: Yes, assuming no change from audit document. Marcelo: We'll make that assumption. 3. Mobile Communication Congestion Exposure Scenario http://tools.ietf.org/html/draft-ietf-conex-mobile-00 D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang, CJ. Bernardos Bob: Would the mobile device trigger offload, or the network? Dirk: Both are possible. The device should be Bob: You don't need conex on the mobile, it already knows there's congestion. John [unintelligible]: Offload to untrusted networks? What are security implications? Dirk: Not treated in the draft at this time. A summarization of the giant congestion terminology derail: Two points: first, there is a terminology problem. Congestion used in conex is used as an indicator to leverage for capacity sharing, not an indication of an pathological situation. Second, it is not clear whether the draft is an example, or is a specification. Bob and Van will sit down offline and talk about this. Matt: there's something that's been bothering me about conex for a while. conex measures control energy. under certain cases: near data is more expensive than far data because it takes more control energy. opening out-of-scope can of worms. conex instruments the network to understand control energy. to move past 1/sqrt(n) congestion control. Andrew: perhaps measure system integrated control energy, as opposed to path control energy. really, with energy, including radio energy. Dirk: Thanks for the comments, moving on... Mirja: Are you planning to talk about AQM? Dirk: no Piers: you talk about offloading, what about stream inloading to a more managed part of the network? Dirk: don't know the answer Mirja: The whole idea if conex is to have control at the end system Piers: Mobile specific solutions, maybe they're nasty hacks but... Nandita: Can we make this more measurement and data driven? WHat happens if you e.g. remove artificial constraints. I encourage you to do measurements, gather data, put in draft. [name unknown]: We need to do performance measurements in this draft. Difficult to compare queue managements. Hard to measure. Nandita: I just want basic data, to answer basic questions. Mirja: are you talking about real measurements, or simulations? Nandita: Measurements. Brian Trammell: this is kind of hard. I want conex to do better measurement -- measuring the network to do cause analysis (and find control energy, in essence) without these signals is hard, so there's a bit of a chicken and egg problem. Very easy to get down in the weeds. Would suggest putting a bit more energy into this. Marcelo: release a new version with running comments, search for additional reviewers. 4. Network Performance Isolation in Data Centres using Congestion Exposure http://tools.ietf.org/id/draft-briscoe-conex-data-centre-00.txt B. Briscoe, M. Sridharan Bob: question: should this be a WG item? under the charter item for experiment. Specific question: should the intuition section be in this draft, or a separate draft. Basically applies to every conex scenario, though if it is limited to a single datacenter. Andrew: should be separate drafts. something that bothers me about control energy dicussion. conex signal does not have dimensions of energy, it has dimensions of entropy. the aggressiveness is a dimensionless ratio, function of QM. (Bob: no)what this really is is temperature -- derivative of energy over entropy. conex signal can be a part of this. Marcelo: would be nice if more people read this, will issue WG adaption in a month? Nandita: please start discussion on the mailing list. Bob: Two threads: engineering thread and temperature thread Marcelo: we want to work on the engineering, data-center thread.