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
