TAPS (Transport Services) BoF IETF 90 Toronto Chairs: Aaron Falk and Michael Welzl Aaron reviewed the agenda and meeting objective to form a new working group. Spencer Dawkins is the sponsoring Area Director. He summarized the previous TAPS BoF meeting in London and that it covered "everything in the world", but this meeting has to be more focused on answering the chartering questions. There are two levels of IESG review for chartering: - internal review: "is this ready to go out for others to review?" - external review: "should this working group be formed?" Spencer noted that the BoF list may be copied on these discussions, as the IESG has started including mailing lists in this process. Brian Trammell TAPS and Transport Evolution: History and Next Steps - The sockets API is not expressive enough for new transport requirements - Brian reviewed past activities up to and including the prior BoF in London - There has been a lot of discussion in different directions (academic work, middleware, etc), but the forward direction was not clear - IAB has been looking at this problem too, concerned with (1) application access to new transport services and (2) improving path transparency - there are slides from the APPSAWG meeting discussing this from Joe Hildebrand (a link was posted in the jabber room) - proposed focus on: - set of existing transport services and which are useful - methods for providing services in context of incremental deployment Michael Welzl The TAPS Charter - Michael described "zig-zagging" of the charter content that has been happening (inserting and removing things) and provided links to the history and list archives - Michael's presentation moved through the charter paragraphs and described what each is supposed to mean Lars Eggert: Is a transport protocol in this definition identical to a transport service, or is it a combination of services? Aaron Falk: A combination of protocols or a set of protocols may provide the set of behaviors that is required for a service; the terminology will be defined as part of this work, and Brian is itching to do that. Need to give applications the flexibility to ask for what they need in terms of services, not just protocols. on the part of the problem statement about finding what works in the network: Dave Thaler: This is not the full explanation of the problem. Falling back to TCP or UDP is not sufficient, since many places drop both and only let HTTP through. It should include HTTP as a possible fallback. BCP56 and Websockets discussion in the charter mentions HTTP. on the deliverables: Joe Hildebrand: if we see good ideas from non-IETF protocols, we should allow them onto the list of services, but the way it is written now doesn't encourage this Aaron Falk: the IETF tends to require strong justification / use cases for doing things, and the output of this working group is an intermediate point; can you give an example of what you're thinking of? Joe: as long as others aren't excluded, I'm fine with prioritizing IETF protocols. MOSH, for example (is one that isn't an IETF protocol) Pete Resnick: asking Joe a question, thinking of the other direction in the stack, and whether IEEE or 3GPP layer-2 protocol features will be requested to be made available to applications Gorry Fairhurst: let's start with ones that we know well, published here rather that a wide list of proprietary and other standards bodies work Lars Eggert: other things aren't under the IETF IPR rules, and you might get things that you don't know the IPR of, even though other people have good ideas Joe: I would be fine with their being a "higher bar" for non-IETF things, just don't want it to be explicitly prohibited Eliot Lear: +1 David Black: +1; also see deterministic networking / 6TSCH in TSVWG Youske Doy (???): what is the transport service along the path? Gorry: This means we need feedback about what works on a given path Dave Thaler: is this set of services mentioned just an example or expected to make other things not on the list require strong arguments to be included? Chairs: no; this is just an example of things we can quickly agree on Dave: thinking about things about mobility, proxy traversal, etc. Brian Trammell: lots of "kilo-comments per word" on this part of the charter; suggest just striking the sentence from the charter Lars Eggert: agree (those are actually really bad examples - not even transport services) Ignacio Solis (PARC): to what degree does the network layer protocol reflect on this API, and is it possible to not use "IP"? Joe Hildebrand: one of the ADs wanted some examples in here, so let's be careful about striking this list; explicitly marking them as examples is easier than striking them in this case Aaron: Lars raised things he doesn't think are transport services that I do. I think of "behaviors" rather than services, and they can be axes where you can turn a knob (degree of reliability, ordering, throughput); is that incompatible with your understanding? Lars: mine is a point on the scale, not a knob that varies. the transport services is the mechanism that delivers data reliably or unreliably. in congestion control, what you choose (CUBIC vs LEDBAT) scores differently in latency vs thoughput Aaron: a bad outcome would be if transport services were just a list of the existing protocols. would you accept that a service might define its congestion control, reliability, and privacy differently? Many in the room: Yes Brian: a service has behaviors ... first thing we need to do is capture the terminology from this discussion Joe: I like thinking of these as points on a continuum, and want to eventually get to the point where behaviors are discrete points Ted Hardie: compile-time set versus real-time choice ... each decision is made when an application defines what to build into its code, if that gets more modular but remains selected at compile time, that's ok, but very different from being selected at run-time Brian: I would suggest on this point that we don't know yet what the model is going to be for using these and don't want to make a decision today ***both are in scope*** Ted: this should be in the charter text Pete: agree with this Ronald in ’t Velt: are you looking at point-to-point only or is point-to- multipoint also included? Gorry: let's start with something we can do (unicast) (much applause and laughter in the room) Aaron: deliberately make this out of scope for the initial charter (we don't know how to do it) Preethi ??? (Cisco): dynamism in the path / changes in the network drive dynamic service discovery, but this is a very big problem to tackle Aaron: there are other deliverables, and I think this comes up in those; there is a third deliverable (Experimental RFC) that describes how you might implement this; let's come back to the discussion Colin Perkins: not here to argue in favor of multicast, but do think this is not the right way to look at it ... RTP is not listed as an example transport by the way ... group communication can be built using unicast, and nothing like that is mentioned; multipath TCP also has one sender and receiver but isn't exactly unicast since there are multiple flows. the charter should either be expanded or constrained more clearly Brian Trammell: I think it would be a gigantic mistake to scope to unicast now, because it could be impossible to adapt to multicast later; agree with Colin that we need language Aaron: can one of you give us a hint what the point is? Brian: charter language has to let us consider behaviors that are exhibited by unicast, multicast, multipath, etc. otherwise it's not going to be relevant, but I don't know how to put it into charter language Andrew McGregor (Google): can think of 2 other things, anycast and termination of TCP connections in CDN Gorry: let's not dig a rathole with multiple exits; scope deliverable to something we can actually do, but allow other things in scope of WG discussion Colin: agree on keeping things focused, but may need term other than unicast for communication between 2 participants Lars: unicast/multicast is a behavior that the application requests just like any other thing Aaron: does anyone feel strongly that the charter needs to define this or can we allow the WG to figure out how to do the right thing? Joe: allow the WG to do the right thing Andrew: +1 Colin: giggling; tempted to constrain it a little in the charter and recharter if we need to try to tackle group / multicast communication Aaron: how about the charter "emphasizes" communication between 2 participants? David Black: I think that's good; it gives the ADs an opportunity to reign things in if the exploration gets out of hand Mo Zanaty: if we exclude group communication, link local multicast or anycast for service discovery could be excluded; also layer-2 behaviors; these are important to the application and services that it wants Aaron: trying to add a layer of abstraction so the application doesn't need to be aware of layer-2 behaviors Mo: requests for a specific behavior should carry through all the layers Joe H.: cringed but could live with the "emphasized" suggestion Dave Thaler: agree and suggest wording, "consider services between two endpoints such as:" Lars: when you say "specify the subset" do you mean write a spec on how to implement? Michael: no just "list" or "document" them Lars: will you have documents that descibe how you provide the services? how do you envision doing this absent specifications for how to provide them? Gorry: not sure what Lars is asking ... are you assuming it's going to define services or protocols? We're not intending to define new protocols, just how to determine what protocols are used. Lars: 2988 (computing TCP retrnansmission timer) has been updated, but do you envision that building blocks like that would be described in stand-alone abstract fasion? Aaron: does app need RTT? room says some protocols do Lars: what kind of documents do we envision coming out of this 2nd bullet? Aaron: modularizing on existing protocols Colin Perkins: following on from Lars ... this makes me think of WGs like RMT that was putting building blocks together, but not sure that's what's being proposed here Michael: this would require developing new protocol, which is not what this intends Colin: the text is not clear on this Gorry: I hoped to actually produce new protocols and machinery, but *NOT* for doing transport, but rather for making them work e.g. Happy Eyeballs Aaron: 1st document "list of stuff" 2nd document select what's included in API Gorry: makes sense to me Dave Thaler: confused on use of passive tense (doesn't say who does choosing or selection), is the audience the person writing code or an application running, or is the intention to be deliberately agnostic Agreement that both are to be included in-scope (compile and run-time) *** charter needs to include notion of audience e.g. application writer Stuart Cheshire: part that makes me nervous is idea that TAPS is meta-protocol doing run- time negotiation go figure out what to use; application writer will look at available options and pick what they think they need, and don't want at run-time to be told that it isn't there Michael: goal of this charter is to focus on things we can agree on as a starting point; this 3rd point is experimental Spencer: need to ask the BoF questions and wrap up discussion; this is actually under a WG review on the IETF discussion list on out-of-scope items: Lars: one minor point, new stuff should be excluded too Eliot Lear: noted a cut-and-paste error Toerless Eckert: QoS discussion deferred (need to discuss offline) Brian Trammell: want to make sure that confidentiality, integrity, etc. are behaviors Yes Colin: transports have quite different security models to TCP Understood and WG will have to deal with Preethi: depending on how service discovery gets done, there could be new kinds of attacks Questions: A. Does the room understand and agree on the problem? solid hum from room Are there people who don't understand and agree? some small number of hummers Scott Bradner says he just doesn't understand Dave Thaler says he hummed against because he thinks others have different understandings B. Is there support to form a WG with the following charter? solid hum C. Does anyone feel that a WG should not be formed? small hum Dave Thaler: just observing that this charter may not be the right one Toerless: think that some charter modifications should be made Aaron: not bolting the charter down; still in IETF review Pete Resnick: hum that this charter is not ready Colin: should a WG be formed once we've iterated the charter a bit more; I absolutely support a WG in this area, but not the specific charter at the moment Spencer: what I'm expecting to happen is that a updated version of the charter will be posted with responses to comments that have been made here and on the IETF discussion list Aaron showed a list of changes he recorded: - follow SFC - add re-charter at end - spelling nits - name change (wiretapping implication) - design-time vs run-time - services between 2 endpoints as scope to be emphasized - audience is developers of apps and stacks Brian: agreed terminology (behaviors, etc) needs to be reflected in charter Stuart Cheshire: rather have "facility" than "behavior"; will engage on list Aaron heard a strong hum that WG should be formed. Disagreements should be taken to the list. Does anyone feel that a WG with the charter modulo upcoming discussion should not be formed? no hums D. Who would be willing to review documents? maybe 2 dozen hands shown E. Who would be willing to serve as an editor for one of the initial two documents? Brian, Michael Tuexen, Gorry, Michael Welzl Spencer: thanks for coming and asking questions; watch for revised proposed charter to come out after the WG review period ends