TAPS WG Meeting IETF 93 Prague Thu 23 July 2015 13:00-15:00 Aaron Falk, WG Chair (Legend: AF = Aaron Falk, BT = Brian Trammell, MW = Michael Welzl, MK = Mirja Kühlewind, KF= Kevin Fall, KN = Karen Nielsen, Agenda 0. Administrivia - blue sheets, note well 1. Review of schedule for taking draft-...-taps-transports to WGLC this year. Schedule: interim call 30 Sept. Doc 1 to be submitted as informational to IESG. Michael Welzl - I am concerned that this will end up as a useless list if we don't take the time it needs. It is more important to get it right than quick. AF - ... but this tends to be driven by the IETF meeting cycle. I don't want people to go to sleep for 3 months after this. Let's turn the crank and see where we are. The question is will be have we achieved our goal? Mirja - We had excellent online discussion. If the current version is not pointing in the right direction, then let's discuss it today. AF - The main point I want to cover in this section is whether there is support for an interim meeting ~end of September? [Joe Hildebrand volunteers to provide WebEx] Brian Trammel - on draft updates: We've had 3 revisions since Dallas. We added a bunch of protocols to the list, then did "dumbest possible merge" of features from each section into one list. We think there's a problem: not much deep insight from compiling a list. We want to capture useful properties... in particular, those exposed by interfaces. Karen and Michael Tuexen will add some text on SCTP. Michael T: Please give us the text for TCP so we can use it as a template. Mirja: Actually, we want SCTP to go first b/c the exposed functions are more explicitly captured in RFCs. 2. Review of protocols we don't have text for yet. Any to add to that list? Deadline for contributions is 31 August. Specifically, text on RTP, Websockets is owed. Varun: I've struggled with the scope of RTP. Not quite sure what to put in the TAPS doc... Gorry Fairhurst: What I'd like to see is not how RTP can solve problems in different ways, or how it interacts with applications. Rather, to see what does it expects from transports it runs over. Varun: OK: It's got sequence numbers, can deal with reordering, and can do FEC... BT: Yup, take what you just said from the notes and put it in the doc. Aaron: These things are stackable, so it also needs to say what things above see when they use it... [?]: Should the text address the use of timestamps? Or see consider them as a second set of sequence numbers? MK: We welcome any text about interfaces before the 31 Aug deadline. Anything we don't have by then we make up or leave out. BT: Provide complete version of doc before interim call... then further review of changes resulting from call. The intent is to start WGLC before next meeting (Oct 20 - Nov 3). Karen Nielson: Will this version address the terminology diffs? [see below] 3. Document review of draft-...-taps-transports Refactored description of TCP components ... BT: [Slide] Components vs. Features - What would/should an application want? proposal: Component = what is implemented in a transport protocol that might be of interest to application. Feature = what an application would/should want to know...knob or meter, application-visible. Example from UDP: ... [shows text] KF: This is making my head bend. Feature = ... BT: That's what we're trying to do... [Discussion among several about what was said/perceived...] Ken Calvert: A part of the problem comes is you are jamming algorithm and wire encoding into "component". TCP uses the same bits with many different algorithms. Mirja: We probably don't want to go into algorithms in this document. [More arguing about terms. Chair allows item 4 on agenda to move up.] APIs as input for TAPS - Michael Welzl Think a lot of this discussion is not advancing taps. motivation: reduce the amount of arbitrariness in the TAPS process, to speed it up and make the result more useful. How to do it? Joe Hildebrand ("IAB hat on"): Agree with you. What's important to stackevo program is to capture what we know, not to put it into the smallest possible number of buckets. Gorry: Yes, it's delayed the process, but it's now giving us the vocabulary to talk about things. MW: There's a list of services we always talk about... Goal = get a list of those and many more. Problem 1: how do we agree what is a "service" and what not? Problem 2: they are heterogeneous in how applications use them. So how do we agree what is a service? ECN? SACK? flow control? Listing components in addition is not making these decisions easier. TCP makes it hard because it has everything integrated, can't turn things on/off. SCTP has a much more decomposed structure. Proposal: go through SCTP's API and we're almost done. Addressing Problem 2: see categories in draft-gjessing-taps-minset: - functional vs non-functional - static vs initialization vs dynamic - single-sided vs both-sided The basic problem he sees: current path won't end up helping when we have to build TAPS API. Suggest starting with SCTP. KF: I disagree with most of this. SCTP is inadequate for TLS, for example. Your characterization may be right, but I think the current draft will help nevertheless. MW: If it helps, fine. BT: The document is not the goal, the process of building the document is the goal. (Replaying a prior conversation...) Part of the issue is that there are dangers in trying to build this system top-down, but also bottom-up. The top-down danger has to do with interactions between components that are not documented, but exist in every installed base. The bottom-up danger has to do with not being able to tease things apart because they are conflated in existing protocols. Yes, arbitrariness so far is annoying, but because of the way things are built, you have to make an arbitrary cut. AF: I think of Doc 1 as a catalog. But we've spent a lot of time talking about subtle philosophical distinctions. That might be useful in a different document - open to discussion of additional efforts. MW: I don't believe in the bottom-up danger. You just say "this protocol has this set of features" and "that protocol has this set." Gorry: I am concerned that we block other things until this is done. Understanding the protocol components is almost a research problem. I suggest trying Michael's thing in parallel. Assume one doc will be philosophical and wisdom-filled, the other will be short and capture what we need to move on in taps. It's a useful document (if the terminology can be harmonized). Colin Perkins: If the goal is to build something that matches the scope of traditional transport APIs, that's one thing. There are other things that are more tightly integrated with applications (e.g., RTP). If the goal is to bring those things into TAPS, the shorter document might not be sufficient. MW: I agree. it's a problem with the existing doc 1: the list is too broad. Hope we can agree that those things are not in charter. AF: It is reasonable to do a big list in Doc 1, then downselect in Doc 2. Mirja: No matter which approach we use, at the end we will have a list of features. Ultimately that's what we want. It is not important for someone who wants to build something to understand all the philosophy, they just need to look at the list. MW: ... but we need to know the decomposability. Mirja: ... but it also depends on how they are implemented. MW: No. We just need to know which features are in which protocol. Mirja: Not every protocol has an abstract API. But the goal is the same in both approaches - may or may not end up with same list in both docs. Fine to have another document, but someone has to write it. Not helpful to have this discussion if we don't have someone to write it. MW: As long as it is implementable, I'm happy. Diego Lopez: The group can make a detailed analysis, but calling them components and features is a bit misleading. Just call it "application interface" - it's what people outside should be expecting from taps. BT: I think the next step is to actually write the other document. Use both as input to the next step. There will be diffs in feature lists, but those are telling us something useful. Regarding categories in Gjessing et al: even this classification is confusing the difference between feature and component (by my terminology). I would like you to fill this out a little more. The differences would be helpful to see where the pain points are in building TAPS. But I wouldn't like to delay the existing one for this. AF: can't have dessert until you eat your vegetables. Gorry: but you can start preparing dessert beforehand! We should go ahead. AF: We won't know effect Mirja: We want to start implementing something, but not convinced that any of the approaches is really right. If we get to the end and find that we did it wrong, can't do anything except go back and do it over. MW: That's what I'm worried about. MK: I am not convinced about your approach either. AF: That's always going to be a risk. MW: I'm not proposing that this be the only way. 4. Discussion: Features (Brian) Took lists from the various protocols, refactored. Who hates this, besides Michael? Is this useful? Should we invest time in doing this for the rest of the protocols? AF: This seems like a lot of work. Do you have concrete examples of what you'll be able to do that's in the charter? BT: When you decompose these into features, you'll have a list of things that either can be separately invoked, or that can't. The point is to throw up warning flags about these things don't split apart very well. Yes, this is a lot of work. But afraid not doing it will not give adequate warning. KN: I like all the details, but they seem kind of random. Some don't seem to belong. I do like the basic idea, but not this particular version. BT: Would you be willing to help do it for SCTP? KN: Yes, but... it's messy for a lot of things in SCTP also. MK: ...then you agree that there should be more text about things that are integrated, just don't like this version of the text. KN: Right BT: I am willing to help with SCTP version? KN: Yes. We will get Michael [Tuexen] to help. Colin Perkins: It is unclear what you can really do with this level of detail. How does it help? Mirja: looking at protocols and coming up with a list that makes everybody happy is not going to happen. So tried this intermediate step. Seems like there was less discussion. Lars Eggert: If we can't even get this right for TCP... MK: TCP is harder! Lars Eggert: ... but adding other protocols is not going to make this easier. Don't understand "we need more text for other protocols". MK: TCP has grown over time, lots of things were integrated... If we had started with other protocols and came back to TCP it would've seemed easier. Colin: TCP should be the easy case. This doc should explain things that are exposed to the upper layers. That's simple for TCP. BT: We can't just say "reliability". KN: I disagree with trying to decompose protocol into components that are only there because they describe a feature. E.g. port muxing was never defined to help with getting through NAPTs. So why put that in there? You are trying to do a decomposition that isn't in the implementation. BT: So keep 3.1.1, 3.1.2, strike 3.1.3, replace 4 with a list of features we'd like to have...? [Brian knows what to do :-)]. Kevin Fall: It seems like this is a lot of discussion about what to write. There's lots of understanding of what the protocols do. Other parts of the doc did a different approach, not bottom-up... AF: (clarifying) The TCP section was rewritten to show an alternative. KF: What is guidance to authors? AF: That's what we're trying to figure out. Look at UDP section. KF: tried to do this top-down as much as possible. We should look at that section and see. MK: I wish we could just write a wish list of features. But don't know how to do that. AF: I think the descriptions in the rest of the document are OK. Michael proposed a different approach, but current text is OK. BT: Are there any objections if we back-out the rev of that section? [no] MK: I'm fine with that, but we might end up with lots of discussion about these one or two word things... BT: I'm afraid people will look at the points and NOT ask "what's this mean?". AF: This doc is a tool, so the people in this room are the ones who need to understand what it means. Don't see it as a high risk for this group accomplishing its goal. Bryan Adamson, relaying comments on Jabber: Transport provides an experience to the application. What about using the application viewpoint to drive this? Also: part of the transport experience is ICMP interaction. What about that? AF: Yes, that is missing from the document. There is not much about what the application learns from the transport. Bryan: This is a deficiency with the current doc. BT: One of the things we are realizing about the architecture is take things that have been implicit and make them explicit. We have this narrow interface to the transport. TAPS is an opportunity to widen the interface a bit. Some of that came out with the ICMP discussion on the list. We forget to ask the question "What can I know." AF: Maybe we don't have to do it protocol-by-protocol, but there may be OS facilities to find out things about what's happening? (Sockopts, etc.?) Gorry: We talk about NORM but not FLUTE. It's probably more deployed than NORM. AF: We need someone to write text. Vincent Roca: I will do it if I have instructions. BT: look at NORM section. Pete Resnick: "I have not written a useful line of code in many years," but part of the problem is that this group can't depend only on me and Stuart at the application layer. Used to have an app that would put up a box that said "received an ICMP notification" with a button that said "so what"? AF: What's the right way to interact with that community? Pete: Stuart, who's doing this? Stuart Cheshire: my view of how it happens: some enterprising person writes a library that they think does something useful and puts it out there. Has to be well-debugged, otherwise it's gated on that person's time to fix things and no one will use it. AF: What can we do to help that person? Stuart: This is a potentiall fruitful approach (but not happening): an application builds its own library that does the set of thngs they think should happen. When the same set of things gets implemented three times, the light bulb goes on and maybe those get factored into a separate library. There's been some of this, but a survey of the various "aspects" that we want would be useful. Would be useful as guidance for library writers. AF: I hear you saying this group doesn't really have the right expertise, it's beyond the stuff we usually do - in other words, there's deeper expertise elsewhere. Stuart: Yes. KF: How about ICMP - it's different v4 vs v6, quite a bit. Do we need to onsider IGMP, ... other control/signaling protocols? AF: We said "prioritize unicast" before. BT: Instead of ICMP per se, we really mean "the ability to get info about why something happened at the network layer." Gorry: The list of things we really need to talk about in this area is actually quite small - for most the application won't know/understand it anyway. Are there more/others in v6? KF: Yes. Gorry: I am happy to work with anyone on that. Does anyone want to help with that? Gorry: When we get to the end of taps, we might just be choosing from 2-3 choices. Even just doing that would be useful - though it wouldn't please everyone. AF: (Time!) Mirja: In the charter there is a mention of LEDBAT as an example of congestion control algorithms that are in scope. The doc has been ignoring "congeston control". Is it OK to continue to ignore them? AF: Not really. We wanted to to cover LEDBAT as an example of a scavenger-type of congestion control that an application might want. We needn't go into detail of the algorithm but (as with the protocols) describe the features. Who knows enough to write some text? [MK raises hand, reluctantly.] AF: I'll introduce you to the document editors. :) Again,the goal is to mention that there are different kinds of congestion control (as is already done in the doc), but it doesn't need to e.g. describe LEDBAT in detail. [Adjourned at exactly 15:00]