tsvarea notes - Martin Stiemerling and Wes Eddy in the chair. ------------- Martin presents agenda, no bashing Martin presents area news - Wes stepping down as TSV AD, much applause to thank Wes for serving SCTP tutorial ------------- Michael Tüxen presents - originally *simple* control transmission protocol - IESG observed that a 100-page spec is not simple - wanted to keep acronym, so now *stream* control transmission protocol timeline of transport protocols - udp - tcp - sctp - udp-lite (udp without checksums) - dccp (udp with congestion control) - mp-tcp (tcp over multiple paths) Discussion: Matt Mathis - observation that one of the advantages of sctp over tcp is really fundamental - tcp has a one dimentional data space -sctp has three dimensional data space means there's a whole lot of stuff you can do with sctp that you just can't do with tcp, feeling that we've only just scratched the surface here. Lars Eggert - for general use on the Internet, is BCP what RTCweb guys are doing with userland implementation and ship with app? or do you know whether rtcweb will fall back to os implementation if it exists Michael - sctp over dtls means it will always be userspace, but fallback scenario is intuitive Randy Stewart - if dtls is in the kernel then problem goes away - not clear that dtls belongs in the kernel… Lars - how much more code for a nat to support sctp Michael - megabytes Dave Crocker - suggestion for a document that discusses a wide range of applications and compares their use for different transports and compares strengths and weaknesses - could be helpful guidance for people making choices about transport protocols in future Toerless Eckert - similar comment - i heard 'sctp is great if you need these cool new features' - many app developers haven't considered whether or not they need these features, just default to TCP. so what is the recommendation - is SCTP always better (modulo middlebox problem)? Michael - depends, use sctp if it provides a benefit to you. tried to focus presentation on potential benefits. if you figure out that tcp is all you need, then use tcp. if you are inbetween unreliable udp and reliable tcp, sctp might help. Stuart Cheshire - PCP - tcp is the way clients talk to a gateway to ask for a port mapping. if multiple devices request same port… i've been told sctp doesn't rewrite port numbers, how can this work? Michael - reason sctp doesn't rewrite port number is .. sctp endpoint is a set of ip addresses and a single port number. sctp nat has no problem rewriting port number as long as you are single-homed. multi-homing means you can't rewrite the port number. Randy - nat that does rewrite needs a lot of CPU to recompute for CRC32C. Michael - intel cards offer hardware support for checksum offloading Stuart - wrap-up is you seem to have a conflict here. you're saying rewriting port numbers is a bad idea, but if you don't rewrite them then i can't have more than one camera in my house. Randy - sctp doesn't have a scoreboard like tcp sack. sctp keeps scoreboard in the sack itself - that's the big difference between tcp and sctp sack - just dawned on me. Matt - interesting you picked on the only MUST in RFC2018 that i wish i could change - that MUST is widely violated in the field as far as I know. AQM discussion -------------- Wes presents introductory slides. Discussion: Jim Gettys - data shows it isn't just an AQM problem - the flow queing is equally or more important - two together are dynamite - we don't have a common term, but would say that bloated buffers must die - how do we get queuing and signalling at the edge of the network sane Wes - need aqm for ecn deployment Matt Mathis - extremely important these algorithms are documented, but don't need to be standardised - shepherd informational RFCs - strongly encourage lightweight informational process, not standards process at all Tim Shepherd - important to realise that things like AQM and ECN are things that need to happen wherever the queue may be in any kind of networking equipment - not just TSV - as Internet gets layered on top of other technologies those other techs need things like ECN to manage their queues in boxes that aren't even IP routers, so I think we need to take message that this isn't just an Internet thing Lars Eggert - we need a drop-tail considered harmful BCP - should come out of IETF process and have an RFC number for procurement - why TSV, because this is where we've started seeing the effect Andrew McGregor - queues can exist above the socket as well, partly application consideration, also partly transport. while individual aqm algorithms may be documented there does need to be standard on what signals between various layers are, especially as some are implicit. there is space for some standards that don't currently exist. Gorry Fairhurst - disagree with Tim, agree with Lars - this is entirely a transport problem - transport is responsible for finding a path that works. publishing informational documents could help Wes George - important for there to be some recommendations in this space - tail-drop considered harmful would be a good first step. real lack of direction on what is right choice - awful lot of AQM options - operators are faced with wide variety of choices, not clear from existing documentation how i should arrive at a decision for my network, tuninng recommendations etc. Jim Gettys - upstream OS that goes into CPE is the key - CPE vendors are shipping firmware based on minimum 5-yr old OS implementations that are misconfigured Wes - this is a variant of the problem of getting good IPv6 support in CPE Richard Scheffeneger channeling Mikael Abrahamsson - well-known problem of bufferbloat - need an RFC similar to 6204 perhaps called queue handling and Michael Welzl - iccrg can publish informational RFCs on AQM algorithms - energy seems to be there on that topic Janardhan Iyengar - very important to understand where boundaries of these mechanisms lie. be clear about where AQM mechanisms work well, and where they don't. second point is about deployment - i agree with idea that we see effects in transport, but deployment needs to happen below transport - how to incentivise deployment. connect tcp to ip metrics to help incentivise deployment. Toerless Eckert - you could leverage the ops area before coming up with a WG in TSV Wes, continues presenting Dave Oran - comment on configuring legacy AQM - there is a fundamentally random relationship between how RED is configured and what it does - if we go down this path we have to do hard work of producing datasets of whether settings actually produce expected results - otherwise recommendations will be meaningless Bob Briscoe - updates to ECN are in tsvwg, so this may be better there as well Lars Eggert - would like fifo considered harmful as first item, doing in ietf (rather than irtf) can help flush out IPR - important for wide implementation Wes - we scheduled this meeting to get feedback - can we have a hum if you think tsvarea should form a wg on this? loud hum Wes - sounds like we should look at forming a wg on this Dave - let's not waste time comparing new AQM algorithms to tail-drop. -------- Open Mic about 'Area Expectaions for TSV ADs' --------------------------------------------- Martin presents Discussion - Alison Mankin presiding: Lars Eggert: text came from previous year's description - revised by TSV ADs year on year Toerless Eckert - how to weigh these requirements against other things that an AD needs to be able to do - being a good manager for the process David Black - i was surprised at how broad the things being asked for were - asking for e.g. 3 out 5 might help - also, chairs of storage WGs are grateful that ADs have never had storage expertise - it's not necessary, good relationships with experts is necessary. also congestion contrl expertise - not necessary to have PhD level knowledge - no what they don't know, no where to find the experts Matt Mathis - congestion control *principles* is really the right level. job description creation process tends to encourage it getting longer -should be a word count limit - as it gets longer it gets harder and harder to fill. advice about aqm and internet was given years ago, didn't get done, now people are surprised to find things are broken - now entering an era where we need to rethink some congestion control principles - so dogmatic answers to some of these questions no longer work - so there's a lot of tension around filling this position. Gorry Fairhurst - this is a list of things that TSV area gets involved in, but this isn't a list of how these things relate to what an AD needs to know Colin Perkins - this seems awfully broad - asking for a superhuman unlikely to result in success - not clear to me that a manager needs to know the details of everything - prune list, or give guidance on what are critical aspects Dave Crocker - some wonderful comments because they draw distinctino between indivdual contributor and technical manager - tend to choose ADs as individual contributors - need anough background to be able to detect bullshit, enough background to be able to detect the quality of the debate and the degree of consensus about different positions in the debate. this area has an opportunity to help ietf move towards AD job being more modest so that you can a larger pool of qualified candidates - need to specify that explicitly Jon Peterson - hope we can inform nomcomm to do something that helps now, not construed as interfering. surprised content delivery isn't a factor in this. scope of area has obviously changed, split of rai area. have discussed idea of area charters in the past - absence of those makes this harder. what are scopes of areas and can they be improved? Magnus Westerlund - what's important is to be able to spot transport issues - I knew some parts of the area when I started the work and you learn quickly - what's difficult is being able to determine consensus in discussions. Lars Eggert - shopping list of area activities is a problem. managing what's going on in the area isn't actually what's important - enough experts show up to keep stupid things from happening. what cause me more work was being the point man on the IESG to spot the issues relating to transport that come up from other areas. i could never make the directorate work for me. could change description to reflect that part more. Sam Hartman - experience as security AD was great, but found that I did have to work without directorate support to deal with issues that required cross-area coordination. how do you evaluate whether or not someone meets these requirements? world 'should' appears a lot - that's fine, but if i'm trying to evaluate a candidate it doesn't say anywhere what attributes a candidate must have. how do you show that you have these qualities? being able to come up with credible answer to when AD-like problems have been managed in the past - if we expect PhD level original research results we're going to struggle. Eric Rescorla - transport similar to security area - difficulty avoiding doing new protocol development that nobody wants - i see a bunch of important things on this list, but what are important places in other areas where transport expertise is required. large development projects - code gets a lot of review, defects arise despite that. if we catch some of the howlers we're doing pretty good, shouldn't expect to be able to find someone that can catch everything. Philip Hallam-Baker - we're a community - can't expect AD to fix broken community - one important role of IESG is to prevent something really bad happening - ability to detect bullshit is key. being able to explain why is also key. 15 candidates need an apology. Allison Mankin - we're not getting into candidate discussion here Jana Iyengar - I don't know any past AD that satisfied this list. if we want someone who can manage bullshit handling, given that they're not an expert in all these topics - we need someone able to enlist experts from their WGs - this is more critical than this laundry list. Bob Briscoe - wnat to emphasise that TSV area needs to speak up for importance of transport area against other areas - sometimes you do have to kill other stuff and detect it early enough so that it's not so painful to kill it. requires a strong person - transport is a larger distributed system than network - transport is about intercommunication between parts of systems that nobody has an incentive to protect on their own - need strength to stand up against vendor interests. Spencer Dawkins - if this list survives this discussion, would be good to have priorities associated. Eric said it best - when we talk about what IESG does, cross-area review is key - and congestion and security always come up. is it possible to factor that out of what's going on there so that things continue to get cross-area review for congestion that we've said we needed for many decades. is it possible to factor in working group management into this list of qualities - we need to get the people who need to be involved, involved. we had a lot of conversations about iesg in early 2000s - every time we talked about what iesg could be was at the level of jacking up iesg and putting something else underneath. we can do process experiments now to figure out what to do when this happens - maybe transport could lead the way here. if succesful that would be a real gift to the ietf. Randy Bush - since everybody is riffing off what Lars said - i think most areas playing catcher in the rye - it's very easy to damage the internet - not just TSV. if you contract out something you don't know how to do yourself, you're going to learn some disgusting lessons. saying that a task requires an academic is not a pejorative. ietf used to be a cooperative of researchers and operators. don't push them away, they're slowly coming back. just those things which everyone agrees are needed - not a laundy list. Dave Thaler - I'm the co-chair of behave wg - we do nats and we're here to break the Internet (much laughter) - let's prioritise these requirements by potential impact on the Internet David Black - agree with Dave Thaler - one and three are probably places where command of the principles is absolutely key. need people on IESG who will act like security ADs that push back on new security protocols when well tried and trusted protocols already exist, but for transport. give nomcomm flexibility to find the best people, not perfect people. people who know what they don't know and how to find the poeple who do is key. Philip Hallam-Baker - thinking about breaking internet - internet very resilient - ADs saving the Internet is hyperbole Kevin Fall - IAB authorities were curtailed in the past - architectural sensitivity is important here, because TSV is sandwiched between layers, and some basic principles of performance are key here, in addition to the soft skills that have been discussed Toerless Eckert - would like to see congestion control principles written up for a case outside the transport area - narrow applicability is the typical get-out for redoing stuff - where do we draw line to define general applicability David Black - transport ads need to have a baseball bat with RFC5405 engraved on it. this stuff has been written down for people who believe they want to use UDP. there are also additonal older documents. Randy Bush - i think it's the swedes that say there's no bad climate there's only bad clothes - we have this idea of a process manager and process being critical - we need better tools - have the tools run the stupid processes Carsten Bormann - second david black's comment. i would be very afraid of transport ADs that were applying RFC5405 as if it was a bible. there are reasons for the 'SHOULDS' in that document, so transport ADs need to understand the finer points. David Black - RFC5405 uses the word 'guidelines' in its title for a good set of reasons Phil Hallam-Baker - we might create a situation that ends up costing Internet operators a lot of money, so large corps should be insentivised to support funding a tsv ad full time. Eliot - been around long enough to see congestion collapse of Internet - question for community is how much do we guard against that. so number 1 on the list is an important responsibility. Ross Callon - if there's an issue here with trying to find a TSV AD this year, it could happen again - so we might want to keep in mind that more people are coming into IETF all the time, some of them might be our future leaders. Alison thanked the participants in the discussion for their contributions. Meeting adjourns.