TAPS@IETF 97 2016-11-16 09:30 Grand Ballroom #2 Chairs Aaron Falk and Zaheduzzaman Sarker started meeting 09:33 Scribe: Kyle Rose and Jake Holland Jabber Scribe: Colin Perkins Note well shown 09:33 Agenda bashing *** = action item Chair updates 3 wg docs: taps-transports, taps-transports-usage-udp, taps-transport-usage 3 related docs: gjessing-taps-minset: bottum up analysis, maybe not minimum mcquistin-taps-low-latency-services, trammel-post-sockets milestones reviewed 1. define set of transport services (done) 2. specify subset of services that taps-supporting systems will provide (in progress) 3. mechanism and implementation discussions (just beginning) progress minset: gjessing-taps-minset mentioned low latency services michael welzl, draft-ietf-taps-transports-usage update 09:41 * brian trammel 09:44- * For the scope of this draft, we leave it at that * None of these provide integrity, confidentiality, or authentication * How do we handle that? * Michael * No response from a query to the TLS list * Aaron * We don't have the expertise in the room * Brian * Will propose a paragraph to add *** * Tommy Pauly * If we want to limit it to specific transports, we should say that * There are other things we're going to want to get from TLS * There are similarly common patterns when you are doing secure transports that are out of scope * Lars Eggert * Have you thought about something like FLUTE (https://tools.ietf.org/html/rfc6726) * Limited by choice of protocols, and all the ones here are kind of similar * Michael * SCTP pretty much does it all * Lars * SCTP doesn't have simultaneous multipathing * Michael * But that is covered by MPTCP * Mirja * FLUTE is in other document we just finished * shook her hands no, this doc should not cover flute. * yoshifumi nishida * something about apis * Michael * * Tommy Pauly * As we're doing this work, MPTCP should look at the API work we're doing and learn from it * David Dolson * Do the documented capabilities include accepting connections as any address (including foreign)? * Michael: it's in the base TCP spec so yes * Wolfgang Beck - 09:53 * Query the send queue length * Real world example: server doing lots of transport over TCP * Renegotiated link from 10G to 1G * Buffer space filled up * Drained too slowly * Michael * Could add an appendix listing things that are important but aren't in any of the specs *** * security considerations *** * Aaron * Need any text contributions from people? * Michael * Intended to write it myself * Would be good to have some contributions * Aaron * Poll the tcpm list * Colin * gorry fairhurst via jabber: "SCTP i-data (ndata)" is nearly ready for WGLC S. Gjessing - draft-gjessing-taps-minset-03 09:59 * should this be a wg draft? (asked by author): 3 hands for "who has read?" +1 jabber-gorry * Colin * Looks consistent * Aaron * Anyone want to speak against adoption? * Tommy Pauly * What direction do we want to take toward making any changes to it * As a minimal set, it does seem quite large * Would we try to minimize it further? I.e, "This is the full set, and we should try to cull things out" * Aaron * Wait * Just move on and circle back to the draft later on, probably online * Mirja * What's different from what we have so far? * Not clear * What's different from the API we have on today's systems? Does it make a big change? * Michael * it is what we have today. * Lists * What you must expose if you want an app to be able to use it * What you don't have to expose * Clearly a TAPS system can't offer capabilities that are not in this list * Which of the functional systems do we really want to provide? * Narrowing that down is definitely of interest * * Mirja * Looks very specific to MPTCP * Not what I want from my interface * Don't want to use MPTCP: I just want something to use for my application * Not sure this is where we want to be * Does this document give an implementor any benefit over what exists today? * Michael * Yes! It tells you which systems are functional * Categorization is what this is about * Steiner * * Brian * Just read the draft now, enough to have an opinion (audience laughs) * Maybe we can take the automatable parts * Wondering why things listed in this draft aren't just additional uses in the TAPS transport usage draft * I think this minimization exercise is useful * Think it can go a little bit further * Wonder if this work just results in additional columns in the TAPS transport usage draft * Make it useful for people trying to find the minimal set * As a consumer of this information, I would find this useful * Tommy Pauly * Folding into the usage set would make sense * Can be minimized further * E.g., I don't want to know if I'm multipath; can this be abstracted out? * Look creatively at how we can specify this * Seems like it's still making things explicit that don't need to be * Maybe come up with a smaller set of common things that can be interpreted per-protocol and maybe end up with a smaller set * Mirja * Giving guidance on how to do automation if you don't * * Michael * Mirja * Stuff on automization can be a separate draft * Michael * Seems fine * Aaron * Still trying to figure out what's going where Colin Perkins - Transport Services for Low-Latency Real-Time Applications 10:15 * Wolfgang Beck: Application can never guarantee a deadline (slide 4, 10:20) * Colin * Transports don't give the option to say "deliver this if you can get it there by X, otherwise discard" * TCP does not meet the requirements of the idealized transport. You cannot do this with TCP. * Wolfgang * ? * Kyle rose: you don't want the stream to just drop if it can't get there inside your SLA * Colin: point is to drop packets that will be useless, not drop the stream. * Colin (continuing, slide 5) * Need expressive dependencies (e.g., want I-frame delivered even if it will be late because P-frames depend on it) * Michael * Colin * *Can* build all of this in an application * But it greatly simplifies the application if the transport service can handle it based on semantic information from the application * Partially reliable SCTP is pretty close to what we want * Don't think there is anything that does all of this, but PR-SCTP is closest * Wolfgang * So, API would expose ... ? * Colin * Proposed minimal extension to sockets API * When you write the data you give it an identifier X, and when you write later you say "this depends on previous data X" * Allows it to choose to drop something that isn't going to be useful to the receiver * continuing slide 6, 10:28 * Asgeir Eriksson * How does the receiver distinguish between "packet loss" and "too late"? * You say it's PR, so sometimes receiver is ACKing packets * Sometimes it's jumping ahead and ACKing packets * How does the receiver ...? * What's different from UDP? * Colin * What's different is that it can rexmit * Asgeir * * Colin * Packets arrive with timing information * Aaron 10:33 - take questions offline please, agenda time concerns * Kyle Larose * Working on developing a network with guaranteed timing, bandwidth * Intention to develop a transport that can make use of these lower-level features? * Aaron * Interface between what applications want and what transports provide * Applications can ask for capabilities * Spencer Dawkins * interest in low latency in a lot of places. it will end up in transport someplace, can't say if taps is right for this or not. * Aaron - promises to walk if this turns into a qos working group. * Kyle Rose - fine line between qos and what this is proposing. colorful latency examples. * Hand-waving latency between earth and moon is like 2.5 seconds * Setting max latency to 100ms wouldn't make sense * So it's up to the application to set appropriate bounds * But what if the route changes out from underneath you (e.g., direct link from earth to moon goes down, so you have to bounce through Mars) * Maybe there should just be notification to user that real-time chat is no longer available * Really want some way of saying "I want at least 90% quality and minimize latency, unless we get below 100ms, in which case I want 100% quality" * Quality is app-specific * Colin - application being able to articulate requirements is useful * Michael Welzl - * Michael Ramalho remotely - has most of these in sctp. is there something outside of partial reliability in sctp? * colin: not really, sctp is pretty close to what they're proposing * Zahed * TAPS as a service needs to talk back to the application: signaling about what the transport is actually able to provide to the application, and signaling about when/how this changes * Some apps don't care about multipath vs. not, but some do * * Jonathan Looney, netflix: use case example: content at high scale, it's important for application to touch sessions as little as possible, needs to dump to transport layer and forget it. however, (as mentioned) there's times when it becomes non-useful if it took too long. lower bitrate for instance. in those cases, it's counterproductive to resend that through transport. at high scale, it's important and useful to let the transport handle it and raise error if there's an issue. could get away with not even notifying the application of failure, and leaving it to client in some use cases. very important, very useful. * Doesn't think radical API change needed * colin: +1 * Tommy Pauley - feedback is important. regarding minimal subset: minimal subset can leave out feedback. something that would work for traditional semantics and also this would be great, something something completions. * Aaron: charter review, and what are we going to do with this? (10:50) * we've identified something not supported which would be useful to have in the api. * sense is that it's out of scope for current charter, but we don't want to lose it. strawman proposal: suppose we turned this into an individual draft, circle back to this at milestone 3, and consider can we add onto this? This maybe is out of scope of charter right now. * Jonathan Looney * Recommend this topic be moved to tsv * Brian * "Yes" to Aaron's proposal to write it up here * Once we've seen a specification of that... * H/2 can use this * Might make sense to understand how SPDY did this * Sticking this in SCTP and having them look at it in 2020 or 2021 is too slow * Michael * Completely agree with Brian (Aaron: get used to it after a while) * Could even see it as a way of selecting and engaging SCTP * Tommy * Agree that protocol specification is out of scope for this * Dependencies are important for TAPS to incorporate * If a protocol doesn't support a concept (e.g., dependencies), it can be grafted on top * Anna Brainstorm * Thinks we could add capabilities not supported by transport * Aaron disagrees because it means TAPS gets bogged down in first milestone * Colin * Brian * This (dependency?) can be just an API trick * Can be seen as an experimental support mechanism * Mirja * something about protocol-independent meaning it's reasonable maybe? * Spencer * Writing drafts is good * Encourages people to write individual drafts * What we're talking about is not in the current charter * Recharter requests that say "we've completed our work, and headed to new and exciting things" go a lot faster than other types of recharter requests * If you think this is really interesting, finish existing milestones first Chairs lost track of time: now rushing through last two minutes Tommy Pauly 10:59, running way late. * aaron: this is a concrete approach in milestone 3. can you do a draft? * tommy: sure *** * mirja, brian, 2 other hands offer to participate in making that draft.