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
