hi Aaron all, The minutes capture the discussion well, to my recollection (though I haven't reviewed against the audio).
Cheers, Brian > On 03 Dec 2014, at 03:00, Jana Iyengar <[email protected]> wrote: > > Aaron, > > I read through the comments and they're accurate AFAICT. > > On Tue, Dec 2, 2014 at 2:45 PM, Aaron Falk <[email protected]> wrote: > I've seen no comments. It would be Really Nice if at least one person could > read the minutes before I submit them for the proceedings. > > --aaron > > On Sat, Nov 22, 2014 at 4:31 PM, Aaron Falk <[email protected]> wrote: > If you spoke up in the Honolulu meeting, please review the minutes to confirm > we captured your point. Thanks to Stuart Cheshire & Michael Welzl for their > detailed notes. > > Thanks, > > --aaron > > ==================================================== > > Transport Services (TAPS) > 1300-1500 HST Tuesday Afternoon Session I > Notes taken by Stuart Cheshire & Michael Welzl > > AGENDA > ======= > 0. Agenda bashing > 1. Charter Overview (Falk) - 10 min > 2. Terminology Review (Kühlewind) - 30 min > 3. Discussion of draft-fairhurst-taps-transports-00 (Kühlewind) - > 20 min > 4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg document? - > 10 min > > Action items marked with ** > > ——————————————————————————————————— > > 13:05 Administrivia > <http://www.ietf.org/proceedings/91/slides/slides-91-taps-0.pdf> > > Aaron Falk: Who was at the TAPS BoF in Toronto? (Most people raised their > hands.) > > Aaron Falk: And who is on the mailing list? (About the same.) > > Aaron Falk: In today’s meeting we’ll be having a discussion of terminology, > and then a discussion of the working group’s first draft. We will be looking > for volunteers. The current draft is an independent submission from two > volunteers: Gorry Fairhurst and Brian Trammell, neither of whom could be > here. We’ll be asking whether the people in the room want to adopt this as a > Working Group document. > > ——————————————————————————————————— > > 13:08 Charter Overview (Falk) – 10 min > > Aaron Falk: The TAPS effort is focussing on the same area as the IAB Stack > Evolution work, which is that there have been 20 years of transport area > improvements that are largely undeployed because (i) the new transports are > not supported in most operating systems, and (ii) the new transports may not > work end-to-end on today’s Internet. As a result, application developers > often build their own protocol on top of UDP, and sometimes that do that > badly. The goal of this group is to enable application developers to get > better performance and better behavior than they can get from TCP or UDP. > > The first task of the working group is to define what these behaviors are > that application developers want to get. We call these “transport services”. > Some examples are: Reliable delivery, in-order delivery, confidentiality, > latency. It’s a way for applications to express what they want from the > transport layer, and to ask for combinations that aren’t currently available > from TCP and UDP. The transport layer then sees what’s available and provides > the best that it can, which might be HTTP over TCP. To do this we’re first > going to examine existing IETF technologies to see what behaviors they > provide, to collect an initial set of behaviors that we think might be > useful. We’re going to focus on communication between two endpoints, at > least initially. That’s the first document, to submit to the IESG next June. > > Then there will be a second document which is a prioritization to select a > subset of those services, and guidance how you might obtain those services > using existing mechanisms. We will submit this to the IESG next December. > > The third document describes how to do discovery of whether these things > work, how to do fallback, how to combine the protocols and make them > available. We will submit this to the IESG in 2016. > > We’re not going to do signaling-based QoS. We’re not going to talk about new > encapsulations and tunneling. We’re not going to define, modify, or extend > transport protocols. We’re not going to define a language-specific API. > We’re not going to do a detailed analysis of security, but we will document > the security properties of existing protocols. The emphasis of this work is > not security. > > Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow > data-with-SYN, out-of-order delivery) > > Aaron Falk: Yes > > ——————————————————————————————————— > > 13:15 Terminology Review (Kühlewind) – 30 min > <http://www.ietf.org/proceedings/91/slides/slides-91-taps-1.pdf> > > (Mirja Kühlewind gave presentation of proposed terminology) > > Dave Thaler: Why not use term “facility” instead of “service component”? The > term “service component” usually means a piece of code. > > Stein Gjessing: “component” means “part”. That’s not a “thing” or “unit”. > > Michael Welzl: I like this a lot. > > Brian Trammell: I’m okay with this suggestion. > > Kevin Fall: Standards Track RFC 2126 defines the term “transport services” as > referred to by ISO. Don’t redefine terms that were already defined by an > International Standard. > > Mirja Kühlewind: Our definition is just a little more specific. > > > Kevin Fall: Reliability is not a binary property. UDPLite has partial > reliability. > > Mirja Kühlewind: We discussed earlier whether we need a concept smaller than > a “service component” for different types of reliability. We call this an > “aspect”. > > Kevin Fall: That term has been reserved as well. > > Joe Hildebrand: Just pick Swiss German words instead, and we’ll all learn > them. This way we have words that don’t have existing meanings in existing > networking standards. > > Dave Thaler: And then we could try using non-US characters in RFCs. > > Mirja Kühlewind: I don’t care what we call it. We just have to agree on some > terminology. Are those six descriptions the right concepts? > > Ignacio Solis: Is “reliability” an example of a “service component”? > > Mirja Kühlewind: Right. A transport service today provides you with a whole > package of service components, not all of which you may want. It also may not > include a service component that you do want. > > Ignacio Solis: We’re being bound by old thinking. > > Kevin Fall: You asked what is missing here. Is it connection-oriented? Is > there connection establishment, notification? Is there flow control? None of > that is mentioned. > > Mirja Kühlewind: These concepts are “service components”; a specific > instantiation would be a “protocol feature”. > > Aaron Falk: The first two terms are things that applications ask for. The > other terms are how you provide those things. > > Brian Trammell: Kevin is describing “aspects”. A “feature” is a thing that a > protocol does on purpose, an “aspect” is something that it does, whether on > purpose or not. > > Gorry Fairhurst: “Feature” is okay. > > Ken Calvert: I would call state establishment “mechanism” I don’t know if > this will ever converge. Don’t conflate wire encoding with logical > implementation. “Mechanism” is wire encoding + function. Why are you not > saying “function”? > > Mirja Kühlewind: For me, the terms “mechanism” and “function” are too > abstract. What you described is still a “feature”. > > Ken Calvert: I suggest not using “reliability” as an example because there > are too many different kinds of reliability. > > Mirja Kühlewind: Do you think we need a term for concepts with smaller > granularity than “component”? > > Ken Calvert: For that concept, use a Swiss German word. > > Mirja Kühlewind: Do we need one more term? > > Ken Calvert: Maybe. > > Andrew McGregor: The decomposition into pieces looks good, but I think > “component” and “feature” should be swapped. > > Mirja Kühlewind: I got this feedback already. > > Jana Iyengar: Well, you just got this feedback again. I agree with Andrew. We > should switch “component” and “feature”. A software “component” implements a > “feature”. > > Mirja Kühlewind: Switching the terms would help? > > (A bunch of “yes” comments from the room.) > > Aaron Falk: That’s consensus. Move on. > > Edward Lopez: We should talk about segregating transport services from > applications. Applications become independent of transport services. We > should start thinking about the rise of transport service gateways. If your > application uses UDP and my application uses TCP then something’s got to > traverse. Is a gateway part of a potential terminology? > > Mirja Kühlewind: I think that’s out of scope. That would be a meddlebox. > > Aaron Falk: The use case we’re focussed on is two applications on two > endpoints. You’re using “application” in a way that’s confusing me. > > Edward Lopez: If we’re talking about transport services and potential > independence from applications, then when a common application is using > different transport services, what’s going to interchange? What’s going to > aid that conversation? That’s what’s not discussed here. > > Aaron Falk: We have pushed that off. The third effort of the working group to > talk about an experiment with end-to-end compatibility. > > Edward Lopez: Then we’d need transport service negotiation. Separation of > application from transport services leads me to think there’s a term missing. > > Mirja Kühlewind: What we want is not that the application is requesting TCP. > What we want is that the application is requesting a certain service > composition, and then the layer below can make the decision to use TCP. > > Ronald in 't Velt: I have not heard the term “element” yet. I agree with > Kevin Fall. Let’s see what’s already there. I have a paper copy of ISO 8072 > somewhere. I couldn’t find it. > > Mirja Kühlewind: I’m sure every term has already been used somewhere. > > Jana Iyengar: We should call them “Thing 1”, “Thing 2”, “Thing 3”, “Thing 4”. > Seriously, how would I think about TCP over IPv6 over SSL over IPv4? > > Mirja Kühlewind: That’s an instance. If you request that service composition > you get that stack. > > Aaron Falk: Jana, what is the application asking for? > > Pete Resnick: The whole idea of how discovery takes place where both > transports talk to each other and say this is the way we’re going to > communicate for this particular instance is independent right now and we’ll > have to figure that out, but it’s not something an application cares about. > We need to talk about feature discovery & negotiation. To address Ken’s > comment, reliability and ordering should absolutely be separate components. > > Stuart Cheshire: I want to follow up to Jana’s point. The choice about what > features to use is not decided only by the application. The choice of TCP vs > UDP is decided by the application, but the choice of Ethernet vs Wi-Fi (with > or without VPN) is decided by the user. Similarly, the choice of VPN or not > may be decided by the corporate administrator, not the application, or the > user. > > Aaron: The application needs to express hints about what it wants. You say > there are other hints. Do we need to add something to our taxonomy that > allows that information to get in? > > Stuart: I don’t think it extends this taxonomy, it might be an orthogonal > dimension. User has an input, administrator has an input, application has an > input. VPN is a classic example: application itself expresses no interest in > security but the user does. > > Andrew McGregor: You can imagine that the API is that the application asks > for a set of components, and the OS decides how to do that. > > Ignacio Solis: We are PARC are building something that doesn’t use sockets. > We have our own terminology. We call the transport layer the “framework”. We > build “stacks” with “components” following the design of composable stacks. > The management component is missing here, especially if we are considering > how this relates to middleboxes. > > Mirja Kühlewind: It would be nice if you could provide some references to > this work on the list. > > Ignacio Solis: We have quite a number of things we’d be happy to share. > > Mirja Kühlewind: You give the application a whole view of what’s available at > the transport layer. This work is to have an abstraction so the application > doesn’t need to know the details. > > Ignacio Solis: We completely agree. The API hides the details of stack > assembly from the application. But the application needs to be able to pick > the entry component. The application needs to be able to pick the API it’s > going to use. > > Dave Thaler: I agree with Stuart’s points. I see a relationship between this > and the MIF working group. The MIF working group is doing similar things here > concerning multiple provisioning domains. The application can express a set > of preferences and get back information about what was chosen. When you > think about the choice of saying which L3 protocol, they say “I’d like to go > across a secure interface” and MIF does the interface selection logic. > > Aaron Falk: Are we re-using any MIF terms or concepts? > > Dave Thaler: I’m not aware of any any terminology collisions. Possibly we may > be using different terms for the same things. The MIF work is complementary. > > Aaron Falk: Who in the room is active in the MIF working group? > > (Dave Thaler plus one other.) > > Aaron Falk: This whole conversation reminds me of DTN. > > Kevin Fall: With DTN we had to develop a pub/sub-style API. We also came to > the conclusion that a third party needs an API to establish a policy on those > bindings. In sockets there’s PF_* and AF_* to express some of these desires. > But the application can also specify the precise protocols using IP_PROTO_*. > It’s useful to take this choice that used to be wired in code and expose it > though an API to an agent. The unit of expressing things is URIs. > > Brian Trammell: So this problem has always been trying to match the crappy > interface above the transport to the crappy interface below. The terminology > (and taps charter for that matter) assume the lower interface can be ignored. > Although that might be impossible from a terminology standpoint. I think > we probably don't want to define a term for the controller... but we might > want to have a way to describe the things that the controller knows about the > lower-interface transport aspects and path aspects. > > Mirja Kühlewind: The goal for right now is to set up an initial terminology > for us to use. > > Szilveszter: Don’t we have to define how to choose a protocol? Is it in TAPS > scope to say how we compose a transport? Isn’t it just an interface towards a > transport? > > Aaron Falk: That is a question about the working group’s scope. The second > document is to pick a subset of all the things an application could ask for. > Right now we’re trying to figure out what those behaviors are. > > Toerless Eckert: Not all of the components here are things that we would > traditionally call “transport”. Some of the components are in INT area. E.g. > what about name resolution? > > Mirja Kühlewind: I believe name resolution is not a component. It’s a > service. This is just a first step. We can still change the terms. > > Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to be > using the same APIs as applications. > > Mirja Kühlewind: Let’s do the first step first. > > Andrew McGregor: Yes, but diagnostic tools require the ability to specify an > exact stack in order to be able to generate the right sort of packet. > > Aaron Falk: That’s pretty clearly out of scope for the group. The goal here > is to make things easier for application developers. > > Andrew McGregor: Is “ping” an application? > > Mirja Kühlewind: This should be hidden from the application. > > Andrew McGregor: The “ping” program is an application? > > Aaron Falk: No, it’s a utility, which is why it’s out of scope. > > Michael Welzl: I remember from the BoF there was consensus that we should > have some kind of determinism to flag to provide repeatability for testing. > > Jana Iyengar: What Andrew is suggesting would be good. We need better tools. > Without deterministic unique composition, how can you have interoperability? > > Mirja Kühlewind: For interoperability we come up with a new shim layer. This > is what we want to hide from the application. > > Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot of > layer violations. This working group has “transport” in the name. Ping uses > ICMP. ICMP is not in the transport layer. To Jana’s point, there’s going to > have to be some sort of rendezvous/discovery. Once an application requests a > certain set of components, how the system establishes talking to the other > side is just something for the lower layers to implement. > > Joe Hildebrand: Let’s agree what the components are before we debate how > they’re negotiated. > > Andrew McGregor: Ping was a bad example. There’s a python library called > “scapy” that lets you specify a bunch of properties and leave the rest > unspecified and it will try and make it work. From incomplete information it > fills in the gaps to make something sensible. This is a practical example of > something that’s already out there. > > Brian Trammell: The factoring of this terminology, if not the words, support > _everything_ we're talking about here. you can ask for a component, you can > ask for a composition, you can ask for a protocol instance. What it doesn't > support describing yet is getting info up from the lower layer. > > Kevin Fall: Identification of the endpoint gives me some concern. TCP has > concepts like ports. Semantics are associated with that. The style of naming > is relevant. > > Mirja Kühlewind: You could have a component “I want to transmit web traffic” > and then naturally the first thing the transport protocol would do is open a > connection on port 80. If that doesn’t work it could do something else. > > Kevin Fall: That’s high level example compared to components like > “reliability”. > > Mirja Kühlewind: This is not for sure. This is the next step. We have to find > out what’s out there and how we name these things. > > Kevin Fall: If these high level examples are what you’re talking about then > high level frameworks well above the sockets layer are relevant. > > Mirja Kühlewind: I just don’t know. > > Mirja Kühlewind: My conclusions from discussion: We’ll switch the terms > “component” and “feature”. This is a good starting point. We can have more > discussions and change things if necessary. We need a term like “aspect” > which is even a lower granularity than “component”. > > ——————————————————————————————————— > > 14:07 Discussion of draft-fairhurst-taps-transports-00 > <http://www.ietf.org/proceedings/91/slides/slides-91-taps-4.pdf> > > Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja Kühlewind. > > Goal is to survey existing transport protocols and extract the common > components they have, and the ways they implement those. > > Slide 4: Relationship between transport protocols and service component > > Joe Hildebrand: There are other IETF areas who should be included (like RAI) > that are not in the transport area but offer transport-like facilities. For > example websocket. > > Mirja Kühlewind: As long as they are IETF protocols they are in scope. > > Dave Thaler: I strongly agree with Joe. Now we’re talking about architecture, > how protocols map to services. I want to go back to what Stuart said about > the multiple parties making the various requests. For example, it is not > (usually) the application deciding that the link-layer should be Ethernet. We > need to avoid the case where the applications at each end request the same > service components but get different protocols and therefore have not > interoperability. What that means is that the mapping from service components > to protocol stacks needs to be deterministic on both ends. > > Mirja Kühlewind: There should be some kind of shim layer that does some kind > of negotiation to make sure they can communicate. > > Dave Thaler: Okay, but the draft does not say that. > > Michael Welzl: This table may look like it proposes a mapping, but it’s just > listing the protocols that currently exist. > > Jana Iyengar: Are we explicitly excluding non-IETF protocols? > > Aaron Falk: Yes, for this work item. We might expand the scope later. > > Kevin Fall: In this matrix UDP is defined as unicast, which surprises me > considering that all multicast work uses UDP. How does multicast fit into > this? > > Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast RESTful > verbs. CoAP also has congestion control, so it’s a transport protocol. > > Mirja Kühlewind: Right now we want to cover all the obvious transport > protocols. If people want to contribute text for others, we can add those. > > Aaron Falk: Andrew, is this an area you have expertise in? > > Andrew McGregor: Some. > > ** Aaron Falk: Andrew McGregor will identify a contributor to describe CoAP > (maybe himself). > > Brian (or Robert?) Adamson, NRL: We should solicit additions via the mailing > list. > > Aaron Falk: Please send text. > > Joe Hildebrand: You asked the question: Is this a viable structure? My answer > is: I think so. But we should start with a detailed analysis of something > like TCP to make sure we understand how that fits the model. > > Aaron Falk: I’d suggest exploring two examples so that we have two data > points. Michael already volunteered to do SCTP. > > Slide 5: Who can contribute? > > Dave Thaler: I’m thinking of a type of protocol that’s missing from the list, > and that’s things like TLS. Applications ask for stuff. Protocols provide > stuff. Applications ask for stuff like confidentiality, integrity, etc. > Protocols like TLS and IPSEC provide confidentiality, integrity, etc. > > Mirja Kühlewind: Please contribute text. > > Dave Thaler: We think in terms of layers, but security is not a layer. It’s > on the side, affecting everything. We need to include the things on the side > too. > > Brian Trammell: Security is definitely an aspect > > Gorry Fairhurst: +1 > > Mirja Kühlewind: “Aspect” or “Component”? > > Gorry Fairhurst: What we want is a plan to make one of these sections > concrete from someone with expertise in the protocol. > > Mirja Kühlewind: Yes. > > Brian Trammell: We're asking the structure question here. > > Andrew McGregor: The structure is ugly but I can’t see how it could be > better. We have to consider how you name the other endpoint. DNS name? URL? > Something else? Should that identity be proved in some manner? How? TLS > certificates? HIP identity hash match. > > Mirja Kühlewind: I don’t need to specify how identity is proved. > > Andrew McGregor: You might if you only have credentials in a particular form. > > Mirja Kühlewind: This restricts what the transport protocol can choose. > > Joe Hildebrand: Let’s not debate API details until we have the principles > adequately characterized. Let’s know what the building blocks are first. > > Aaron Falk: I agree that we should flesh out a couple of sections and use > that as a basis for refining the rest of the document. Who will volunteer to > take on one of these sections? > > ** Kevin Fall: Open mouth, insert work. I will do UDP. > > Mirja Kühlewind: Are there no MPTCP people here? > > Aaron Falk: What about basic TCP? > > ** Mirja Kühlewind: I will do basic TCP, but it would be good to have other > people too. > > Varun Singh: Is RTP excluded? > > Mirja Kühlewind: Will you do that? > > ** Varun Singh: I’ll contribute text for RTP. > > Varun Singh: Is this document on GitHub? > > Mirja Kühlewind: Gorry Fairhurst and Brian Trammell can decide that. > > Brian Trammell: I can move to markdown over GitHub, no problem. > > Kevin Fall: Are the lessons we learn here going to reflected in the previous > document? > > Mirja Kühlewind: This document just lists what’s there. > > Kevin Fall: If we discover that idempotency is an important concept, how does > that get added to the document? > > Joe Hildebrand: Finding those is the point of this exercise. > > Aaron Falk: We’ll give you a cookie. > > Varun Singh: It seems like we’re going to replicate a lot of text from > existing RFCs. > > Aaron Falk: The goal is to take an existing protocol and identify what > services it is offering to the application. That’s what we want to get in > this document. > > Mirja Kühlewind: What you as an expert for some protocol should do is > describe the protocol as completely as possible. > > Dave Thaler: What are you looking for in each section? Service components? > Protocol features? Both? > > Aaron Falk: I want the protocol components, but the way you get there is to > analyze the protocol features. > > Mirja Kühlewind: Please provide text. > > ** Dave Thaler: I volunteer to help with getting the matrix right, of > features vs. things that are protocols, e.g. inherent vs. optional is another > key thing for features. I’ve done such work in the past. It’s useful to know > which things are inherent features, and which things are optional features. > For example, with TCP you can have keepalives or not. > > Mirja Kühlewind: The first step is to describe the protocols. > > ** Dave Thaler: I’m volunteering to help with the matrix more than the > specific text, but I may be able to do some of that too. > > Jana Iyengar: Let’s not end up with a giant matrix and checkboxes for various > features. That’s not useful. > > Mirja Kühlewind: There may be cases where two components do not work together. > > ** Karen Nielsen: I will provide SCTP text. > > Karen Nielsen: Protocol features like ACK or NACK are not specific to TCP. > SCTP also has ACKs. You can’t say that protocol features are specific to one > protocol. > > Mirja Kühlewind: Protocol features are specific to one protocol. > > Karen Nielsen: So SCTP ACK is different to TCP ACK. > > ** Pål-Erik Martinsen: I will provide text for STUN > > Charles Eckel: It will be helpful to combine everything into one table. > > Mirja Kühlewind: Having a single matrix would be really nice for the > document. But the first step is to describe the protocols and extract the > components they provide. > > Kenneth Calvert: Is one of the goals here to come out with an ontology of > transport service components? > > Aaron Falk: We are trying to confine the scope to IETF protocols. A complete > ontology would not necessarily be useful. > > Kenneth Calvert: For this draft, before you plunge into the matrix, it would > be useful to define the existing components. > > Mirja Kühlewind: This is the end goal of the document. > > Brian (or Robert?) Adamson, NRL: Is there a template for a list of the > aspects we care about? > > Mirja Kühlewind: This is just an initial attempt. > > Brian Trammell: To Kenneth, “yes” (but I am allergic to the word ontology.) > > Gorry Fairhurst: To Brian (or Robert?) Adamson: That’s the entire point of > this working group. > > Michael Ramalho: This is a very hard problem when I think about how some of > these protocols were evolved to meet very special needs. Suppose I have this > application that doesn’t want head-of-line-blocking, and maybe I don’t want > to retransmit once or twice, and let’s suppose I have something expressive > enough to convey this to the transport layer, and it can’t deliver this > without using multiple TCP connections, and maybe I would have preferred > DTLS. How do you express that to this layer? > > Mirja Kühlewind: The document is focussed on the simple cases first. > > Pete Resnick: It would be a terrible failure if, in such situations, the > transport layer would ask the application what to do. The app doesn’t care > and doesn’t know. That I can pull this off with 3 TCP connections is not > something the app cares about. You either give the app what it asks for or > fail. > > ——————————————————————————————————— > > ** 14:43 Aaron Falk called for adopting draft-fairhurst-taps-transports-00 as > WG document. > Folks who read the draft: maybe 10 + > Significant hum in support > None against > > -- END > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
