Subject: Re: [Taps] draft minutes from IETF-91 meeting

From: Aaron Falk <[email-masked]>
Date: Tue, 2 Dec 2014 17:45:48 -0500

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-masked]> 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
>

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 2 Dec 2014 18:00:32 -0800

Aaron,

I read through the comments and they're accurate AFAICT.

On Tue, Dec 2, 2014 at 2:45 PM, Aaron Falk <[email-masked]> wrote:

>>           4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg
>> document? - 10 min
>>
>> Aaron Falk: Who was at the TAPS BoF in Toronto?  (Most people raised
>> their hands.)
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Ken Calvert: I suggest not using “reliability” as an example because
>> there are too many different kinds of reliability.
>>
>> 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”.
>>
>> Aaron Falk: We have pushed that off. The third effort of the working
>> group to talk about an experiment with end-to-end compatibility.
>>
>> 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
>> 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.
>>
>> 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.
>>
>> Brian Trammell: So this problem has always been trying to match the
>> crappy interface above the transport to the crappy interface below. The
>> 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.
>>
>> Dave Thaler: What are you looking for in each section? Service
>> components? Protocol features? Both?
>>
>> 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.
>>
>> Gorry Fairhurst: To Brian (or Robert?) Adamson: That’s the entire point
>> of this working group.
>>
>> ** 14:43 Aaron Falk called for adopting
>> draft-fairhurst-taps-transports-00 as WG document.
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 3 Dec 2014 11:20:35 +0100

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-masked]> wrote:
> 
> Aaron,
> 
> 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
> 
> 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
> 
>           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
> 
> Aaron Falk: Who was at the TAPS BoF in Toronto?  (Most people raised their hands.)
> 
> 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.
> 
> 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
> 
> Dave Thaler: Why not use term “facility” instead of “service component”? The term “service component” usually means a piece of code.
> 
> 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.
> 
> 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”.
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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”?
> 
> Andrew McGregor: The decomposition into pieces looks good, but I think “component” and “feature” should be swapped.
> 
> 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”.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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: 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”.
> 
> Goal is to survey existing transport protocols and extract the common components they have, and the ways they implement those.
> 
> 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.
> 
> 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.
> 
> Michael Welzl: This table may look like it proposes a mapping, but it’s just listing the protocols that currently exist.
> 
> 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 McGregor will identify a contributor to describe CoAP (maybe himself).
> 
> Brian (or Robert?) Adamson, NRL: We should solicit additions via the mailing list.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Andrew McGregor: You might if you only have credentials in a particular form.
> 
> 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?
> 
> ** Mirja Kühlewind: I will do basic TCP, but it would be good to have other people too.
> 
> Kevin Fall: Are the lessons we learn here going to reflected in the previous document?
> 
> Kevin Fall: If we discover that idempotency is an important concept, how does that get added to the document?
> 
> 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.
> 
> ** 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.
> 
> ** 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: 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: 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.
> 
> Brian (or Robert?) Adamson, NRL: Is there a template for a list of the aspects we care about?
> 
> 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?
> 
> 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.

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 03 Dec 2014 12:28:55 +0100

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

-- 
------------------------------------------
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-masked]
------------------------------------------

---

From: Aaron Falk <[email-masked]>
Date: Fri, 5 Dec 2014 08:52:15 -0500

Ack.  But I like 'meddlebox' better.  :)

--aaron

On Wed, Dec 3, 2014 at 6:28 AM, Mirja Kühlewind <
[email-masked]> 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.
>
>>> document?
>>> their
>>> Stack
>>> a
>>> services”
>>> that
>>> there
>>> Andrew.
>>> group
>>> say
>>> asks
>>> available
>>> crappy
>>> second
>>> TCP.
>>> of