Ack. But I like 'meddlebox' better. :) --aaron
On Wed, Dec 3, 2014 at 6:28 AM, Mirja Kühlewind < [email protected]> wrote: > Hi Aaron, > > I've read the minutes but as at least my statements are all reflected > correctly, I didn't further response to your mail. > > Thanks a lot to the minutes talkers! The minutes document the meeting very > detailed and well and therefore are very useful! > > As I now writing away, please introduce two small changes: > > 1) I'm pretty sure I've said 'middlebox' and not 'meddlebox' (even though > meddlenox might actually be the more accurate term in some cases...) > > 2) s/We need a term like “aspect”/We might need a term like “aspect”/ > > Thanks, > Mirja > > > > On 02.12.2014 23:45, Aaron Falk 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 >> >> > -- > ------------------------------------------ > Dipl.-Ing. Mirja Kühlewind > Communication Systems Group > Institute TIK, ETH Zürich > Gloriastrasse 35, 8092 Zürich, Switzerland > > Room ETZ G93 > phone: +41 44 63 26932 > email: [email protected] > ------------------------------------------ >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
