TAPS IETF-98 Chicago Tuesday, March 28, 2017 4:40 PM CDT Note taker: Kyle Rose 1. Administrivia and Chair’s Blah-blah - 10 min 2. Working group document updates - 20 min 2.1 draft-ietf-taps-transports-usage-03, Michael Welzl •Aaron (chair): what's about TCP Auth? who is going to write it? •Michael: one hour work, I shall write it. •Aaron: ready for WGLC? •Michael: yes. •companion UDP usage document ◦Michael: IP layer functions, should they stay or go? ◦Gorry: ask the WG? UDP lite is a funny beast. like to continue with the document. ◦Michael: suggestion to make them standout as a part of generic IP things ◦Aaron: may be the title of the document is "UDP and others" ◦Michael will help Gorry. ◦Tommy Pauly asked about history of separate documents ◦Gorry: they are separate documents because they were written separately ◦Aaron: kept separate for managability, include text to point to the companion document •ACTION: Tommy will volunteer to review Gorry's UDP document •ACTION: Both documents need to be revised and then going to WGLC, review the UDP document, Micheal to write about TCP Auth 2.2 draft-gjessing-taps-minset-04 , Stein Gjessing •Call for adoption •Aaron: call for hands of people who read the draft ◦2 raised hands ◦Gorry: read the draft. Document seems as it should be. Not controversial. If the WG want a document in this space then it should be adopted. ◦Tommy Pauly: Agree with that. Certain parts in the discussion area that we should have more discussion on; word-smithing needed. A good thing to adopt: it has the right core in it. ◦Aaron: anybody from remote has a say on this? ◦Brian Trammell: "Yeah, do it." ◦Hannes Tschofenig: one question on scope, Are you trying to cover security layer into account? Shouldn't this cover security? for IoT any API document includes guidance for DTLS would be useful. ◦Aaron: Tried to get someone from security directorate to participate, but no one did, so we stuck with the stuff we knew. Would be useful to have an equivalent of TAPS that handled security stuff ◦Tommy: Any practical API guidance will need to include security. Can't leave it out. Is it possible to have another draft in TAPS that is the minset of security features ◦Aaron: might be a charter scope change, but might be entirely appropriate ◦Tommy: would try a draft with min-set format to include security features. ◦Aaron: Hannes would you be interested in this? yes. lets talk about it in the next meeting. ◦Gorry: Originally security was in-scope. would be cool to look at such draft. 3. TAPS Design Discussions - 60 min 3.1 Messaging, introduced by Michael Welzl •Brian: Where is the boundary between application and some sort of library to handle slicing? like minion and hollywood. •Michael: The point here is to make it compatible with TCP. •Brian: If a particular application protocol has a pre-existing framing mechanism, the sender is using TAPS, and the receiver plain TCP, TAPS would abstract the framing away from the application on the sending side but be understood and dealt with explicitly by the receiver. Implementation level details. •Aaron: Good idea: needs refinement ◦ACTION: Refine idea •Colin Perkins: If wire format is unchanged, but the parsing is moved from the application to the transport stack •Michael: your need a signaling protocol. •Colin: no. •Michael: My understanding is that you need the receiver to be TAPS-aware •Tommy Pauly: Point is not to create new protocols, but to take what we have and offer them as a service. Other side doesn't have to treat the transport as messages. If we're writing messages and what's underneath is truly a bytestream, all we're doing is scheduling how my chunks of bytes in TCP or in a TLS stream arrive with respect to ordering. •Michael: If we can make it work, I'm all for it. •Tommy: I think is does work. •Lars Eggert: Thinking about datacenter and low lantency, in the future, we'll want to replicate memory writes to a remote machine rather than serialize/deserialize ◦Is this a transport service that TAPS is looking at, or are we always serializing/de-serializing data? ◦Expresses concern about the cost of s11n/d13n •Aaron: Out of scope •Gorry: is there another way of doing (pointin to Lars's comment) it than TCP way of doing it? •Michael: not sure what Gorry is asking. This is a fall back to TCP mechanism. •Colin: follow up on Lars's point. Should Discuss the security implications of what Lars was suggesting. •Aaron: sounds like a bar-bof topic. 3.2 Multi-streaming, introduced by Tommy Pauly •Michael: in min-set it says for multi-streaming the only application specific info required is priority of the streams.Speaking for option 3. Spoke about grouping and how that applies to different transports depending on what's available ◦as long a you know what the group is and what priorities applied then you can do it transparently.Thats the assumption here. ◦Opening and closing of connection is also not a big problem here, you establish connection by sending data. •Tommy: a TAPS aware receiver can receive a HTTP stream and treat it at its level. •Micheal: yes, but in QUIC or SCTP there will be nothing on the wire when connect is done. ◦Sending something to server to make request is a conner case. •Colin: Does the API change if you rule out raw TCP vs. TCP with some streaming structure (e.g., HTTP/1.1) on top? •Tommy: if you can guarantee that your protocol is multi-streaming aware then option 1 and 2 is more viable. But it does introduce a whole new bunch of error condition and such. •Colin: how do I use RTP on top of this? cannot see how to do this with option 3. •Tommy: not familiar with such semantics. •Colin: Requests are not completely independent ◦Some protocols have subflows that are aware of each other •Michael: Maybe being able to query about the transport would be sufficient •Kyle: Not sure query about a specific protocol is sufficient. Want to use TAPS explicitly because I don't want to know exactly which transport I'm using, but instead just want transports with specific characteristics 3.3 Early data transmission, introduced by Michael Welzl •Tommy: Not sure it is the best way to expose fast open. Can use characteristics of messages (e.g., idempotent) to give the transport some flexibility in how to handle it, such as sending it via TFO or TLS 1.3 0-RTT (or QUIC 0-RTT) 4. Related Projects - 30 min 4.1 Happy Eyeballs, Naeem Khademi •Aaron: State of implementation? ◦Naeem: All implemented and available on GitHub •Colin: Starting to look a lot like ICE (interactive connectivity establishment WG) ◦The extensions they have are things that you'll need ◦Conceptually, something very similar •Aaron: See lots of puzzled faces ◦Probing end-to-end and using heuristics to decide on what's working •Colin: ICE does connection racing ◦Details are different, but conceptually similar •Aaron: Similar problem that could be learned from •Colin: (paraphrased) yes •Tommy: Happy eyeballs is a bit higher-level ◦The race itself could use ICE ◦Great if document could go more into how to schedule fallback ◦Current approach is "do it simultaneously; see which works better, and remember" ◦When we do happy eyeballs for addressing, we keep everything on the table, because conditions may have changed •Phillipp Weinrank: Concern about burning resources on the server side dealing with races •Naeem: Haven't looked into that. Something to consider. 4.2 NEAT, Naeem Khademi •Aaron: Endpoints are going to discover which protocols do and do not work. Have you given thought to sharing that information? •Naeem: You mean between entities? •Aaron: Maybe centralize it. Might be helpful to discover which carriers are breaking standard protocols. Is this part of the scope of stuff you're thinking about? •Naeem: we have not arrived to the state to do large measurement but think it is possible to do that. •Gorry: Notion of collecting results of probing/races is a necessary element of a system like this. Likes the idea of collecting information and making it available to the user 4.3 Post-Sockets, Tommy Pauly •Hannes: There exits diversity of elements for security (certificate types, roots of trust). How do you deal with all of these? •Tommy: Maybe provide a security object that encapsulates and abstracts the implementation of the security "stuff" to whatever is specific to the application •Lars: "aside from the link going down how long message going to be kept locally before you send them? •Tommy: hopefully not too long •Lars: Then do you really need this? •Tommy: These are coming from real-time stuffs , like playout buffers. •Brian: Looking for people to write applications. Really looking for wider input on this from actual implementors. •XXXX from Google: What about padding for security and privacy reason? •Tommy: Would be nice if the application didn't have to worry about the specific security properties (e.g., padding) •Kyle: Maybe need to be able to enumerate and choose security properties in the same way we choose transport properties. Maybe confidentiality of bits is good enough, but maybe we also need to be resistant to traffic analysis