TAPS (Transport Services) Thursday 2016-07-21 18:30-19:30 Chairs: Aaron Falk and Zaheduzzaman Sarker Room: Bellevue Minutes: Kyle Rose and David "Tale" Lawrence Jabber scribe: Colin Perkins *** Chairs update - 5min https://www.ietf.org/proceedings/96/slides/slides-96-taps-7.pdf Zahed: need for "northbound" information. taps abstracts complexity as much as possible, but apps need to know what lies beneath. - custom behaviour based on transport - need to know especially why things are not working - have more info about svc cost and want to tailor traffic based on that, not just at start but while in use later too - require session mobility, for addresses at either endpoint *** Update on draft-ietf-taps-transports-usage - 10 min (Naeem Khademi of neat project) – updated draft promised by the authors. https://www.ietf.org/proceedings/96/slides/slides-96-taps-5.pdf 1. added some explanations clarifying nomenclature 2. Christoph Paasch contributed mptcp 3. Update "rules" to allow inclusion of experimental RFCs TLS chairs feedback: - lots of docs ref TLS without describing API - lots of features also not described in TLS spec - lots of options that depend on X.509/PKIX make it a lot more complex Conclusion: dont have expertise or motivation within taps to write that section Future plan: - sctp beyond RFC 4960 - tcp experimental RFCs - dccp included *** Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry Fairhurst for neat) – already updated. https://www.ietf.org/proceedings/96/slides/slides-96-taps-1.pdf Running code with high level api, neat_{open,accept,read_write} for udp All done with what planned to do. Merge into -transports-usage draft? Or keep as separate doc? Tale: I like smaller pieces. Spencer Dawkins: fine with taking docs through in smaller pieces. Don't use NFSv4 as a yard stick. If there are normative cross references, they will tend to move together. Gorry: Any reason just to keep it as one? Aaron: Nothing substantial. *** Update on draft-gjessing-taps-minset - 10 min (Michael Welzl also for neat) - updated draft promised by the authors. https://www.ietf.org/proceedings/96/slides/slides-96-taps-0.pdf Trying to document the trade-offs for a feature-rich API covering all possible transport features versus a simpler to grok system. Aaron: in the interest of starting a small argument Brian Trammell: Dang, *I* wanted to start an argument. Aaron: Are we going to make an effort to expose aspects of multi-path? Brian: Hey that was my argument. Aaron: Wait, are you saying the document is basically done? Michael: No. Aaron: So where's the bit about what needs to be done? Michael: draft-ietf-taps-transports-usage isn't finished and this document needs to grow along. *** Investigation on the use on happy eyeballs for transport protocol selection - 10 min (Anna Brunström, yet more neat) https://www.ietf.org/proceedings/96/slides/slides-96-taps-4.pdf Slides based on IRTF ANRW paper: https://irtf.org/anrw/2016/anrw16-final27.pdf Set up three different test cases between a web app (linux) through a network emulator (linux) to a web server (freebsd). Unencrypted and TLS encrypted, with no caching; then with caching. Adding TLS quadruples CPU utilization, much larger change than just adding happy eyeballs. Overall conclusion: Happy Eyeballs is a feasible transport selection mechanism, especially with caching. tsv lib with HE on http://github.com/NEAT-project/neat See draft-grinnemo-taps-he Tommy Polly: How realtime are these? Simultaneous? Anna: Yes Tommy: Apple experience is that staggered races seem to mitigate a lot of CPU overhead factors. Can we do something like that? Anna: Try your preferred protocol a little bit earlier, but initiate the backup just in case the preferred protocol doesn't work Tommy: In addition to a priori preference would like to have some kind of learning. Anna: Caching allows you to remember when a recently-tried protocol didn't work, so you don't try it again too quickly Steven ?: Not going to answer the question but want to make some trouble: how do you manage it in app layer vs network layer? Realtime apps do it with ACE, but it's a bit messy. Can something cleaner come out of taps? Anna: this is why we started with sctp Tommy: We have some experience with double happy eyeballs between address families and interfaces. Now here's a third layer. Varun: ICE working group had similar results. Colin Perkins(?) did some experiments with this on NAT. The number of combinations was really large though, so it made a huge amount of traffic just for connections. UDP and not congestion controlled, so all you could check was the timer. This sort of thing seems to really demand congestion control for feasibility. If you come up with guidance on HE here, ice would take it into their wg. Colin: Yeah this is essentially ice, so there is some scope for co-operation. *** Post socket - 10 min (Brian Trammell) https://www.ietf.org/proceedings/96/slides/slides-96-taps-2.pdf SOCK_STREAM is yesterday's interface. Limited, but it makes the network look like a file, so simplicity wins (or won, at least in the 1970s). Really good interface for getting a tape from one side of the room to the other. SOCK_SEQPACKET, "tomorrow's interface, yesterday". Solves a lot of problems but is bound to sctp which hasn't succeeded. Some insights or assumptions: Apps deal in objects/messages, ordering not as important Let transport solve optimization. Network of future is explicitly multipath. Future transports demand security Message reception is already inherently async taps lets you select transport but if each one has its own API, not useful. neat api is one solution, but if apps have to change anyway then PostSockets is an alternate, more radical approach that can be used. Read Colin's paper about my [Brian's] awesome API. Colin: related - the last presentation coming in the session; also, Clark and Tennenhouse paper on ALF (SIGCOMM, ’85?) Tommy: I think this great and I like your model; the tricky thing is to get everyone to agree on it and use it. Early on you need to get implementers on it. *** Socket intents, Leveraging Application Awareness of Multi-Access Connectivity - 5 min (Philipp Tiesel) https://www.ietf.org/proceedings/96/slides/slides-96-taps-3.pdf Want to be able to have application specify the intent of the socket. Tried minimal approach modifying addinfo struct to bsd socket api. For connection reuse though really need a different api to connect, choose or release. On github https://github.com/fg-inet/socket-intents *** Implementing Real-Time Transport Services over an Ossified Network - 10 miin (Stephen McQuistin) https://www.ietf.org/proceedings/96/slides/slides-96-taps-6.pdf Also https://irtf.org/anrw/2016/anrw16-final25.pdf Name?: Something about SCTP? Brian: Really awesome stuff. Looks like you're now drafted to get into the group of stack people to make it better. Would like to see larger scale measurements. Aaron: Thanks everybody for staying late. Looking forward to Korea and will try to get a longer slot. close() reap()