Tuesday, 1300-1500 Afternoon Session I (Pearl) ============================================== Rolf W (RoW) - probably last meeting - want to wrap up - this is a working meeting - we want your input! Administrivia 10 minutes - Scribes (Meeting Minutes & Jabber) - Blue Sheets - WG and document status RoW: very little activity in the group lots of support for forming WG - activity has dropped off dramatically since formation need to come to closure on congestion control draft hoping for more activity and input now that we are close to being done. congestion control (CC) draft is top priority for publication other drafts are interesting, but they are lower priority for WG WG will close once CC draft is done. If other docs are not done by then, it's up to authors what they want to do. It would be nice if we can get all docs done by closure of WG, milestones are there for a reason after all. authors of congestion control draft have disappeared off the face of the earth. chairs have appointed editors - janardhan iyengar and mirja kuehlewind multiple connections draft seems dead. A Survey of Lower-than-Best-Effort Transport Protocols 20 minutes (draft-ietf-ledbat-survey-01) David Ros (DR) presents looking for an additional detailed review - already have two [Mayutan, Mirja] Mirja Kuehlewind (MK) - ledbat itself is not bound to a specific protocol, right, so therefore I would keep app stuff in here, but look at each approach RoW - won't move this forward without another review Lars Eggert (LE) - adding lots of text may not be a wise at this stage - and to reviewers: send text if you think something should be added or improved - otherwise this isn't going to make progress DR - will get this done by the end of the month, assuming that people react on the mailing list RoW - happy to see the effort to conclude this work, there is little time left however, so I hope we see people reacting on the list. Low Extra Delay Background Transport (LEDBAT) (draft-ietf-ledbat-congestion-03) Rolf/Murari RoW - who has read the latest version of the doc? Maybe 5 hands Any comments on the new structure? Shall we assume that the structure is fine? Stuart Cheshire (SC) - can you elaborate on why you think applicability to TCP seems too far out? Murari Sridharan (MS) - repurposing TCP timestamps to OWD is a reach LE - had this discussion when we chartered ledbat - we were more optimistic about the energy in the community - it has been lower than we hoped. original intention was to define the algorithm and then maybe we would recharter to take on application to transport protocol. hopeful that someone will take the output of this WG and make it work for TCP, but that obviously won't be in this WG. RoW - won't retain statement that this is applicable to all transport protocols MS - UDP can stay MK - we do have TCP implementation of ledbat SC - Apple engineer has got this working in TCP - haven't had time to independently verify this - might not change removing the claim from the doc, but there is energy going into this. MS - we're not saying it can't be done. End nodes have to agree that timestamps will be used in this different way. need additional agreement mechanism, so this isn't trivially straightforward. LE - happy to hear this, please write it up for TCPM, or maybe somewhere else. MK - where is 100ms coming from? RoW - good observation, had the same question re 25ms. Current thinking is that there is an implementation out there using 100ms, in future you might want to do something different, so the doc will say less than 100ms is OK. MK - so shall we state this reasoning in the document RoW - what does the WG think? i'm making the comment as a contributor, not as WG chair. 100ms is a lot, but it is currently implemented reality. LE - agree - these are two reasons we should put in the draft - there is existing code, and going lower means you will be out-competed by 100ms code. cite the ITU recommendation as well. MS - Rich Woundy (RiW) - have looked at a bunch of interactive apps to see where they break - tends to be 300 - 400 msecs for the games. VoIP tends to be most brittle. RoW - is this documented somewhere? RiW - there's a presentation to a cable show somewhere SC - sounds like there's consensus that we'd like to say 25ms, but we don't have any experience with this. So we say 100ms that we have experience with and allow people to try something lower. RoW - will ask again on the list, give a 2 week comment window, and then make the consensus call, but agree, does seem like we have consensus in this room at least Dave McDysan (DM) - are there other parameters that would allow somebody to game this algorithm? MS - appropriate MUSTs and SHOULDs are critical here to ensure fairness. SC - we don't need to agonise too much about fairness - apps that are using this have already made a decision to play nice RoW - not sure I agree - competing apps in the same space may have motivations to try to deliver better performance by increasing the base delay very slightly. this should be discussed in the draft. Random reshuffling for fairness slide RoW - have results that demonstrate latecomer advantage SC - Stas Shalunov (SS) asserted that OS scheduler would give enough randomness, I asked how much randomness was needed, didn't get a response. Don't hold up the document for this, if we don't have a firm answer then leave text vague 'some amount of randomness is believed to help' LE - people implementing this should experiment with this. does adding more entropy improve behaviour they observe? this might be an improvement but we really don't know and we need someone to tell us. MS - don't know if BitTorrent do this in their implementation today SC - quite certain they don't as SS asserted that entropy of OS scheduling would deal with this. But it won't if we're talking about MacOSX. MS - if you have few connections then the synch problem seems real, but we don't have data. RoW - who thinks new structure is better? few people have read the doc, but those that have like the new structure MS - there is text in the document that is speculative about alternative mechanisms - should we keep this? LE - if you keep it, put it into an appendix, and make it clear that consensus applies to text outside the appendix. don't see a huge reason to keep it though. MS - clock skew text is in the appendix. MK - about the speculative text, don't see need to remove it - it's in the appendix, it's useful for the record. MS - what concerns me is that either the authors believe that what they have deployed works, or they don't. why discuss alternative mechs unless you're not confident about the specificed mech. RoW - unfortunately asking the authors doesn't work MK - taking this discussion out would be a pity if someone wants to refer to it in future. MS - not suggesting we remove all the text, just the speculative random stuff MK - i found it interesting to read, so am reluctant to remove it RoW - so let's ask this on the list RoW - Rich Woundy - what's up with your doc? are you still pursuing this work? RiW - draft was about use cases where it made sense to have multiple parallel connections - as we went through use cases in prior meetings, we kept running up against contradictions, so I'm spooked about touching this document right now. Have had feedback that the work is valuable and worth progressing. Are chairs going to keep the list going? We could do it there and consider a private submission MS - not worth keeping the list open for this doc LE - keeping list open doesn't cost us anything, so we can do that. doc was short and to the point, but it's an orthogonal topic. so maybe you need to refactor aggressively and produce a shorter doc that only contains what you can agree on. that would be better than giving up and walking away. RiW - that sounds doable RoW - agree, you should try to restart this effort, focus on the bare minimum, and then we'll see if there's something worth publishing. and soon please. LE - current author team should consider whether they have the cycles between now and Prague. If we need to add a new author, then it might help if one of the existing (5) authors could become a contributor to allow recognition of any new author as such. RoW - we're not going to make an attempt to revive the working group, so this needs to happen quickly or not at all. RiW - keeping mailing list up is cheap and easy, we do this all the time. we're still not at AUTH48 LE - we leave WGs chartered until all docs are out of AUTH48, so need to keep ledbat around until then. But yes, intent is not to meet in Prague. But we are now entering the holiday period. CC draft is close to done, but other two look like they need more work. MS - I thought we agreed that draft won't be progressed in this WG. LE - yes, thanks for reminding me. :) RoW - it's up to the authors how to progress their work RiW - build a backwards timeline, if gates are missed then it's slow track MS - do the authors still believe there is value here? RiW - as it's written now, maybe not. slimmed down, maybe yes. my feeling is that something can be salvaged. agree with LE suggestion to slim it down. DM - RFC3662, RFC3594 - recommended usages of DS codepoints, different handling at different congestion points in the network - might be worth adding a comment in this draft, rather than the CC draft MS - two kinds of fairness - intra-ledbat and inter-ledbat LE - are you saying that some draft should recommend that DS codepoint is set? DM - it's mentioned. this would be a practice recommendation. RiW - for practices draft have some concerns - high priority thing is to remove text, not add it. in terms of a recommended practice, if it doesn't work operationally then it seems strange to recommend it. and wouldn't it be better to cover this in conex? DM - yes that's another option. LE - i don't think this belongs in multiple connections draft. proposal for CC draft is to say that you might want to mark DS codepoint, but don't expect anything to happen. you could say you might want to mark ledbat traffic with this codepoint and in the event that it is deployed you might get some benefit. MK - I wouldn't want to get into the potential complexities here in any draft. MS - one of SS concerns was not getting penalised twice. RoW - editors need to tell us what dates will work before we can circulate a timeline on the list. MS - we can react based on input from author team that they do have energy to slim down this draft RoW - personal preference is that you go somewhere else. not convinced that drafting a timeline will necessarily result in action. rushing things isn't good either. not convinced ledbat is the right forum for this work. need energy for reviews as well. meeting ends