-------------------------------------------------------------- CONEX WG Agenda IETF-81 Meeting -------------------------------------------------------------- 0. Agenda Bashing, Minute taker 5 min Discussion on home for TCP modifications. Conclusion was to let the area directors decide what to do with it if the WG decides that it is useful. 1. Congestion Exposure (ConEx) Concepts and Abstract Mechanism https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/ Bob/Matt 15 min Matt: Would like to last-call this and hold it until concepts-uses converges. Marcelo: Just last call it, can always reopen if necessary. David Dyson: There's an implicit assumption that all the sources are using conex. Matt: If you make that assumption you fail to deploy; it has to work under conditions of partial deployment. There has to be something good that happens for the people that are doing it right. Marcelo: One thing I'm concerned about is the straw-man encoding. Are you planning on changing that? Why can't we use something for IPv6 when that's what is in the charter, and the straw-man is for IPv4. Matt: It's a one-line change to use that encoding unconditionally in today's stacks, for experimentation. Marcelo: But it's looking for trouble. Bob: Would it to be acceptable to say "assume there is a bit (which there is not in Ipv6)"… Matt: I can make the language less conspicuous. Nandita: What exactly do you plan on including about flow-state? Matt: Examples to show auditing/policing can be achieved without detailed per-flow state, and others where more state would be helpful. 2. ConEx Concepts and Use Cases https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ Bob/Rich 30 min David Dyson: I think the timescales are quite important, and should be put back. Jana: It sounds like clarifying what timescales you are talking about would be a good thing. Nandita: To prevent congestion collapse, doesn't the non-controlled traffic have to have conex markings? Bob: Yes. Marking proxies could do this. David: I like the numerical examples, if you do this then you already have introduced the concepts and demonstrated what happens with and without conex. The thread has been that you don't get to the main point into very late in the document. Early on you can show policing etc. Matt: Communications problems, we tend to assume what is going on. Shep: You mean per second or per interval Nandita: examples are good David: 6.2 I really like, having a diagram that illustrates the major use case, then maybe once you show that continue with the numerical example, and that would improve the flow of the document. Bob: There would be so much to describe, the whole deployment section we propose to push to another document. So we don't have to explain the abstract concepts again and yet get to talk about deployment. David: you could reference that, show the basic diagram and examples. Bob: See if we can do an example without showing how it is done in the network, and see if you like that. Say, imagine the operator limits how much congestion volume you can send in a particular period, and then go on. Bob: Traffic management has some political overtones and became a point of contention. Alissa: Traffic management is about things other than merely managing congestion. I'd withdraw any objection to traffic management, so long as there's acknowledgement of the broader scope of it. Alissa: I was hearing a lot that you wanted to make traffic management the centerpiece, and that's why collapsing it all into a section on traffic management seemed to make sense in the structure of the document. The congestion collapse case is also somewhat a consequence of having the traffic management infrastructure, so it might be easier not to include it. Nandita: I think it's OK to sacrifice some accuracy in the interests of simplicity, since everything is peripherally related to traffic management. Marcelo: this document has proved to be hard to write. It would be a relative success if a reader can read up to section 3 and clearly understand it. Let section 4 be for the expert. Bob: I don't want application authors to fail to see the applicability. Marcelo: I'd be happy if just the operators would see the point. Alissa: The scavenger transport could be a one-liner Matt: An important concept is tutorial, and cases that are true but not easy to explain have negative benefit, even if they're still true. Congestion collapse and scavenger seem to be examples, they may be better removed for the purpose of this document. David: There's also an internal contradiction. Leaving out scavenger creates an internal inconsistency??? (not sure I captured the point) Bob: For ages we have been saying there are three main use cases, now we're talking about leaving out two of them, and I think it would severely weaken the document. Marcelo: Let's try the new structure, let's see if we get the first three sections clear, and then let's see if adding the rest makes it confusing. Matt: So, there's another process detail. There's a flaw in the ietf process that obscures a process we could be using. It is possible to use fragments of text that are copyrighted but otherwise unformatted, so we could park fragments in another draft for a bit. Marcelo: Since there is no opposition, we'll try the document split w/ new deployment document. 3. IPv6 Destination Option for Conex https://datatracker.ietf.org/doc/draft-krishnan-conex-destopt/ Suresh/Mirja 15 min Andrew: Please don't try to make the switches do anything but count set bits. i.e. keep this format how it is. Suresh: Using a destination option allows AH (IPSEC Authentication Header), therefore tamper proofing the bits. Bob: When a policer was dropping, it was then very difficult for the sender to know if that was congestion or not. There is a case where it gets caught in the policer. There is a possibility to allow a policer to communicate forward that it is dropping for policy reasons. Matt: There are some issues with ambiguity between distinguishing between policing and congestion. Marcelo: Are you OK with doing immutable, and doing something else later if it proves necessary? Bob: Yes. Many in favor of adoption, none against. Matt: A stand alone section can be referenced from elsewhere, if it is useful, and that doesn't need to be a separate document; may not be worth the overhead. 4. Accurate ECN Feedback in TCP https://datatracker.ietf.org/doc/draft-kuehlewind-conex-accurate-ecn/ Mirja 10 min Matt: Is it known if there is any ECN nonce code deployed? The only implementations I know of were in academic settings. Ken Calvert: Were you planning on doing any testing to see if these bits were broken in the network? Or is the intent to mostly rely on comments on the list? Mirja: There is no option for getting accurate feedback AND retaining precisely existing ECN or option behavior. Bob: Another sort of experiment might be, for the 3-bit counter scheme, how often do you lose sequences of pure ACKs that would wrap the counter? Matt: There are some scale assumptions here, how about TSO and RSO issues? Andrew: TSO and RSO don't deny you information Matt: There are some that do… (oh dear…) Marcelo: Question will be, do we work on this accurate ECN document? 5. TCP modifications for Congestion Exposure https://datatracker.ietf.org/doc/draft-kuehlewind-conex-tcp-modifications/ Mirja 10 min Bob: I assume this draft will pick one scheme and not give options. Marcelo: You mean between the classic ECN support modes? Mirja: These are sender-only options, you can only do one at a time, but it's your option. Bob: I believe we need the accurate feedback, it's useful, may take longer to get through other groups. Mirja: But do we need it for conex? Bob: Yes. Then does it hold up the TCP mods? Trying to get an answer. Marcelo: We handle the process, we just want to know if it has to be done. Bob: Conex is only intended to be used with an auditor. Not doing this creates a disincentive for deployment, as you would get poorer performance. Nandita: sounds like an optimization Bob: In Mirja's measurements, around 30% of losses are in TCP overshoots, so inaccuracy will be quite large in practice. When you overshoot, everyone gets losses. Matt: Part of the problem we have with TCP is that there is not adequate fidelity in the feedback, and we don't want to dig that hole deeper, so you want to get more information to the sender, independent of conex. x: The cause is helped if one of the draft points to a need for this sort of thing. So if someone could fit it in elsewhere, that would make it easier for this to go through here. Marcelo: We'll try to do this, and talk to area directors and other chairs to try and get it done. 6. Conex for mobility http://tools.ietf.org/html/draft-kutscher-conex-mobile-01 Dirk 10 min The WG meeting ran out of time for this final presentation.