Minutes for TAPS at IETF-91
minutes-91-taps-1

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 middlebox.

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 might 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