CONEX WG meeting TUESDAY, July 27, 2010 9:00-11:30 Morning Session I ________________ Title: Agenda bashing, minute takers Presenters: Chairs Time: 5 mins. ________________ Title: Conex Use cases and concepts Presenter: Bob Briscoe Time: 60 mins. Show of hands for who has read use-cases draft - about half of those present Dave McDysan: do you mean scheduler when you say queues? BB: Queue controller if you like DM: so this could be work conserving, or non-work conserving, right? BB: yes DM: so congestion could fit into either of those definitions? BB: yes DM: would be good if current draft made that clear Jana Iyengar: what's the one-liner (to define the problem that conex is addressing)? BB: ??? BB: I'm asking you that question! list owns that problem Continuing with slides... DM: you're talking about the network use case, isn't there also a use case from the user perspective where there's a non work conserving scheduler and the user is congesting that? like a rate-limit or a volume-limit? BB: if that non work conserving thing is limiting on congestion you need to be careful about feedback loops. if not limiting on congestion then you're probably alright DM: so this talk about use cases or mechanisms? BB: both - mechanisms that can use conex, but not conex mechanisms Marcelo Bagnulo: - good point - let's speed up and focus on the use cases BB continues with presentation… DM: do you believe there is the same timeliness requirements for all use cases? BB: no, what you want to do is make it so that if the source and the receiver want to be sluggish they have to be more conservative in how much congestion they declare - that's a personal view - needs discussion on the list. Ingemar Johansson: timeliness requirement sounds tcp oriented BB: no i was thinking especially of RTP, where you need to be more conservative initially due to slower response to congestion Tim Sheppard: are you making any assumptions about the other boxes areoun ISP Z being ECN enabled? BB: No, that's a personal view as well - need to discuss this. We shouldn't have to make any assumptions about ECN. Question from Jabber - ECN would be the better means but we might be able to use loss as well BB - yes, i'd modify what i said to agree with that - ecn is the easier way Lei Zhu - do you want to distinguish sender and receiver on application data BB - out of scope for conex, but could be a use case that the net op would use the data in that way, but haven't thought about that Fred Baker - Congestion Control slide - 'introduced' is a bit much - there's lots of history here BB: yes Alissa: ISP that's implementing conex is incentivising those behaviours among users of other ISPs BB: yes, we hope Discussion --------- MB: first, let's talk about whether this use case makes sense. Think about how many use cases we want to have then we can discuss this specific document. Chris Morrow: DoS mitigation - bad actors don't respond at all to congestion control notification - would remove this - we can already deal with DDoS mitigation BB: you're saying that putting a DDoS use case in this draft is unnecessary aggravation for people CM: Yes. Congestion is at tail-end, so if the window that you have to deal with is very small, then time to react is a concern - 1RTT seems overly long BB: you have to start with credit - you're not always a round-trip behind - you have to start off in front Fred Baker: agrees regarding the DDoS question. you have a much simpler use case - service provider can be in control of queues. regarding number of use cases - question is is this enough for working group discussion, is this good enough for a WG draft. i'd argue yes. BB: Fred has also previously pointed out that encouraging use of congestion control is another important use case FB: encouraging people to target the knee rather than the cliff would be good Janardhan Iyengar: if we have a sufficient number of use cases then let's go ahead with the sufficient subset and then work on a bis document to gather additional use cases. clarification re conex use cases intro slide. isn't ISP Z a src and dst network? BB: slide clarifies that this could be reversed, but IESG wants it this way around. Matt Mathis: usage scenarios should be independent, not sequential. also ask 'does this usage scenario add clarity' and delete them accordingly. BB: traffic management scenario has three subcases DM: try to look for commonalities amongst use cases, and try to align them with abstract mech draft. map to common abstract terminology, e.g. response time BB: digital fountain - never any feedback - can design conex to deal with that DM: use cases shouldn't use word 'mechanism' this doc needs major surgery to fix this MB: please send detailed review highlighting text that is broken and proposing alternative text DM: I can do a more detailed pass, yes Dirk Kutscher: I think this is good enough for WG adoption. Agree with what FB said re expending effort to explain relationship with existing concepts like ECN and Diffserv. concerning use cases, need to use them to show what conex could do and derive some requirements. could add to list of requirements. ingress policy for P2P etc. would be good to have this incorporated. Ruedigger ?: replacing bandwidth brokers to manage admission control for QoS - any assumptions on traffic aggregation - document should clearly state… MB: are we going to adopt this document or not? several changes need to be made before we can consider this question. Leslie Daigle: reiterating remarks sent to mailing list. for progressing the content in the WG, but document needs to be split into two. important to consider how these docs will be read 2 years from now. use cases will change, while mechanism remains constant, so mixing these isn't helpful. will also help clarify our discussion. MB: we are chartered to define an abstract mechanism - so you want to see this document as well? LD: yes. putting both in one doc gets to far into mechanism and then that discussion gets undermined by particulars of use case being considered BB: IESG have to read this doc first LD: IESG may be capable of reading two documents at once Lars Eggert: charter is a little unusual in its staging of deliverables BB: less about mechanism is better? LD: i guess Alissa Cooper: today's presentation had a lot less about the mech than the draft does, so align doc with today's preso and we've made progress ________________ Title: Requirements of Localised Congestion Notification Presenter: Lei Zhu Time: 10 min (revised slides not marked 'Huawei Confidential' should be forthcoming) Nandita Dukkipati: How does this relate to conex charter? LZ: Make congestion visible to user - most congestion in access network, so access network congestion is part of this. DK: would help if you explain what is missing from current conex scenario. is this a new use case, are you proposing to extend current conext concepts? MB: so you are describing an additional use case? LZ: yes, i think so DK: what are you missing from the existing mechanism, usage scenarios? seems like they already cover this. MB: please consider trying to write this as a use case ND: please pay particular attention to how and where conex is being used - didn't see that in this, so not convinced its relevant to this WG IJ: you don't need to use ECN -just measure uplink buffer capacity MB: we need to wrap this up - let's move the discussion to the mailing list ________________ Title: ECN and TCP Slow Start - A motivation for a more scalable congestion control Presenter: Mirja Kuehlewind Time: 20 mins. Jabber comment: ECN Syn Cookie support was recently added to linux kernel MK: yes, but not kernel version I was using. IJ: Scenario 1 - blue line is debit mark? MK: this is the balance - positive minus negative DK: this was interesting - it's good to see that congestion exposure works, but to say that for real but we need to see interactions with policy MK: would be interesting, yes, I'm not an ISP Ali Began (Cisco): ssthresh is 20? is that a typical value ND: much higher by default in linux MK: our reduced value was 22 AB: any recommendations for practical ssthresh? ND: latest linux code has Hybrid slow start - suggest you take a look at that Tim Sheppard: Comment to whole WG - observation that conex works - interesting to see that this is implementable, but for conex to be useful on the real Internet it has to be trustable and secure - so can't yet argue that this works based on our current level of experience - can't demonstrate that conex works from a demo MK: two separate things - proposed protocol works ________________ Title: CONEX abstract mechanism Presenter: Matt Mathis Time: 20 min DM: question assertion that you can't provide feedback in less than RTT - if you have congestion on egress queue could get feedback in half-RTT MM: can do link-layer feedback CM: it wasn't link-layer - all these nets are very large, complex beasts - trying to figure out whats happening is hard, and it happens for less than an RTT scale time period MM: yes, but the earliest a marked packet can inform the sender is after 1RTT CM: yes, but that's late MM: can fix things with link-layer flow control, but then you get head of line blocking BB: wanted to add that conex isn't saying congestion control has problems, just trying to count it and know who is causing it. MM: mech allows everyone along the entire network path to see the full path congestion DM: if i discriminate retransmissions MM: you're mixing re-feedback marking with dscp marking DM: i'm just about the proposed retransmit tag LE: this only works for protocols that retransmit MM: yes, any protocol that does reliable delivery Ken Carlberg: Why distinguish between black.ecn and black.loss MM: in order to measure losses the network has to reconstruct the tcp state which is an expensive operation. cheating checks really only work on black.ecn BB: i don't think you need to do all this trying to mirror tcp in the network in order to have a scenario where you may be able to deal with cheating for loss. networks with trusted endpoints useful for other reasons. but in iesg scenario - most congestion is seen by one node that is doing the drop and can check that conex markings are correct. MM: abstract spec mapped onto real implementations JI: seems to me that you don't need a reliable transport - you need something that gives sender feedback that there was loss MM: reliable needs retransmit, congestion control needs signals