Minutes for TAPS at IETF-93
||Minutes for TAPS at IETF-93
TAPS WG Meeting
IETF 93 Prague
Thu 23 July 2015
Aaron Falk, WG Chair
(Legend: AF = Aaron Falk, BT = Brian Trammell, MW = Michael Welzl,
MK = Mirja Kühlewind, KF= Kevin Fall, KN = Karen Nielsen,
0. Administrivia - blue sheets, note well
1. Review of schedule for taking draft-...-taps-transports to WGLC this
year. Schedule: interim call 30 Sept. Doc 1 to be submitted as
informational to IESG.
Michael Welzl - I am concerned that this will end up as a
useless list if we don't take the time it needs. It is more
important to get it right than quick.
AF - ... but this tends to be driven by the IETF meeting
cycle. I don't want people to go to sleep for 3 months after
this. Let's turn the crank and see where we are. The
question is will be have we achieved our goal?
Mirja - We had excellent online discussion. If the current
version is not pointing in the right direction, then let's
discuss it today.
AF - The main point I want to cover in this section is whether
there is support for an interim meeting ~end of September?
[Joe Hildebrand volunteers to provide WebEx]
Brian Trammel - on draft updates: We've had 3 revisions since Dallas.
We added a bunch of protocols to the list, then did "dumbest possible
merge" of features from each section into one list. We think there's
a problem: not much deep insight from compiling a list. We want to
capture useful properties... in particular, those exposed by
Karen and Michael Tuexen will add some text on SCTP. Michael
T: Please give us the text for TCP so we can use it as a
template. Mirja: Actually, we want SCTP to go first b/c the
exposed functions are more explicitly captured in RFCs.
2. Review of protocols we don't have text for yet. Any to add to that
list? Deadline for contributions is 31 August. Specifically, text on
RTP, Websockets is owed.
Varun: I've struggled with the scope of RTP. Not quite sure
what to put in the TAPS doc...
Gorry Fairhurst: What I'd like to see is not how RTP can solve
problems in different ways, or how it interacts with
applications. Rather, to see what does it expects from
transports it runs over.
Varun: OK: It's got sequence numbers, can deal with
reordering, and can do FEC...
BT: Yup, take what you just said from the notes and put it in
Aaron: These things are stackable, so it also needs to say
what things above see when they use it...
[?]: Should the text address the use of timestamps? Or see
consider them as a second set of sequence numbers?
MK: We welcome any text about interfaces before the 31 Aug
deadline. Anything we don't have by then we make up or leave
BT: Provide complete version of doc before interim
call... then further review of changes resulting from call.
The intent is to start WGLC before next meeting (Oct 20 - Nov
Karen Nielson: Will this version address the terminology
diffs? [see below]
3. Document review of draft-...-taps-transports
Refactored description of TCP components ...
BT: [Slide] Components vs. Features - What would/should an application
Component = what is implemented in a transport protocol that might be
of interest to application.
Feature = what an application would/should want to know...knob or
Example from UDP: ... [shows text]
KF: This is making my head bend. Feature = ...
BT: That's what we're trying to do...
[Discussion among several about what was said/perceived...]
Ken Calvert: A part of the problem comes is you are jamming
algorithm and wire encoding into "component". TCP uses the
same bits with many different algorithms.
Mirja: We probably don't want to go into algorithms in this
[More arguing about terms. Chair allows item 4 on agenda to
APIs as input for TAPS - Michael Welzl
Think a lot of this discussion is not advancing taps. motivation:
reduce the amount of arbitrariness in the TAPS process, to speed it up
and make the result more useful. How to do it?
Joe Hildebrand ("IAB hat on"): Agree with you. What's
important to stackevo program is to capture what we know, not
to put it into the smallest possible number of buckets.
Gorry: Yes, it's delayed the process, but it's now giving us
the vocabulary to talk about things.
MW: There's a list of services we always talk about...
Goal = get a list of those and many more.
Problem 1: how do we agree what is a "service" and what not?
Problem 2: they are heterogeneous in how applications use them. So how
do we agree what is a service? ECN? SACK? flow control?
Listing components in addition is not making these decisions easier.
TCP makes it hard because it has everything integrated, can't turn
things on/off. SCTP has a much more decomposed structure. Proposal:
go through SCTP's API and we're almost done.
Addressing Problem 2: see categories in draft-gjessing-taps-minset:
- functional vs non-functional
- static vs initialization vs dynamic
- single-sided vs both-sided
The basic problem he sees: current path won't end up helping when we
have to build TAPS API. Suggest starting with SCTP.
KF: I disagree with most of this. SCTP is inadequate for TLS,
for example. Your characterization may be right, but I think
the current draft will help nevertheless.
MW: If it helps, fine.
BT: The document is not the goal, the process of building the
document is the goal. (Replaying a prior conversation...)
Part of the issue is that there are dangers in trying to build
this system top-down, but also bottom-up. The top-down danger
has to do with interactions between components that are not
documented, but exist in every installed base. The bottom-up
danger has to do with not being able to tease things apart
because they are conflated in existing protocols.
Yes, arbitrariness so far is annoying, but because of the way
things are built, you have to make an arbitrary cut.
AF: I think of Doc 1 as a catalog. But we've spent a lot of
time talking about subtle philosophical distinctions. That
might be useful in a different document - open to discussion
of additional efforts.
MW: I don't believe in the bottom-up danger. You just say
"this protocol has this set of features" and "that protocol
has this set."
Gorry: I am concerned that we block other things until this is
done. Understanding the protocol components is almost a
research problem. I suggest trying Michael's thing in
parallel. Assume one doc will be philosophical and
wisdom-filled, the other will be short and capture what we
need to move on in taps. It's a useful document (if the
terminology can be harmonized).
Colin Perkins: If the goal is to build something that matches
the scope of traditional transport APIs, that's one thing.
There are other things that are more tightly integrated with
applications (e.g., RTP). If the goal is to bring those
things into TAPS, the shorter document might not be
MW: I agree. it's a problem with the existing doc 1: the list
is too broad. Hope we can agree that those things are not in
AF: It is reasonable to do a big list in Doc 1, then
downselect in Doc 2.
Mirja: No matter which approach we use, at the end we will
have a list of features. Ultimately that's what we want. It
is not important for someone who wants to build something to
understand all the philosophy, they just need to look at the
MW: ... but we need to know the decomposability.
Mirja: ... but it also depends on how they are implemented.
MW: No. We just need to know which features are in which
Mirja: Not every protocol has an abstract API. But the goal
is the same in both approaches - may or may not end up with
same list in both docs. Fine to have another document, but
someone has to write it. Not helpful to have this discussion
if we don't have someone to write it.
MW: As long as it is implementable, I'm happy.
Diego Lopez: The group can make a detailed analysis, but
calling them components and features is a bit misleading.
Just call it "application interface" - it's what people
outside should be expecting from taps.
BT: I think the next step is to actually write the other
document. Use both as input to the next step. There will be
diffs in feature lists, but those are telling us something
Regarding categories in Gjessing et al: even this
classification is confusing the difference between feature and
component (by my terminology). I would like you to fill this
out a little more. The differences would be helpful to see
where the pain points are in building TAPS. But I wouldn't
like to delay the existing one for this.
AF: can't have dessert until you eat your vegetables.
Gorry: but you can start preparing dessert beforehand! We
should go ahead.
AF: We won't know effect
Mirja: We want to start implementing something, but not
convinced that any of the approaches is really right. If we
get to the end and find that we did it wrong, can't do
anything except go back and do it over.
MW: That's what I'm worried about.
MK: I am not convinced about your approach either.
AF: That's always going to be a risk.
MW: I'm not proposing that this be the only way.
4. Discussion: Features (Brian)
Took lists from the various protocols, refactored.
Who hates this, besides Michael?
Is this useful? Should we invest time in doing this for the rest of
AF: This seems like a lot of work. Do you have concrete
examples of what you'll be able to do that's in the charter?
BT: When you decompose these into features, you'll have a list
of things that either can be separately invoked, or that
can't. The point is to throw up warning flags about these
things don't split apart very well. Yes, this is a lot of
work. But afraid not doing it will not give adequate warning.
KN: I like all the details, but they seem kind of random.
Some don't seem to belong. I do like the basic idea, but not
this particular version.
BT: Would you be willing to help do it for SCTP?
KN: Yes, but... it's messy for a lot of things in SCTP also.
MK: ...then you agree that there should be more text about
things that are integrated, just don't like this version
of the text.
BT: I am willing to help with SCTP version?
KN: Yes. We will get Michael [Tuexen] to help.
Colin Perkins: It is unclear what you can really do with this
level of detail. How does it help?
Mirja: looking at protocols and coming up with a list that
makes everybody happy is not going to happen. So tried this
intermediate step. Seems like there was less discussion.
Lars Eggert: If we can't even get this right for TCP...
MK: TCP is harder!
Lars Eggert: ... but adding other protocols is not going to
make this easier. Don't understand "we need more text for
MK: TCP has grown over time, lots of things were integrated...
If we had started with other protocols and came back to TCP it
would've seemed easier.
Colin: TCP should be the easy case. This doc should explain
things that are exposed to the upper layers. That's simple
BT: We can't just say "reliability".
KN: I disagree with trying to decompose protocol into
components that are only there because they describe a
feature. E.g. port muxing was never defined to help with
getting through NAPTs. So why put that in there? You are
trying to do a decomposition that isn't in the implementation.
BT: So keep 3.1.1, 3.1.2, strike 3.1.3, replace 4 with a list
of features we'd like to have...? [Brian knows what to do
Kevin Fall: It seems like this is a lot of discussion about
what to write. There's lots of understanding of what the
protocols do. Other parts of the doc did a different
approach, not bottom-up...
AF: (clarifying) The TCP section was rewritten to show an
KF: What is guidance to authors?
AF: That's what we're trying to figure out. Look at UDP section.
KF: tried to do this top-down as much as possible. We should
look at that section and see.
MK: I wish we could just write a wish list of features. But
don't know how to do that.
AF: I think the descriptions in the rest of the document are
OK. Michael proposed a different approach, but current text
BT: Are there any objections if we back-out the rev of that
MK: I'm fine with that, but we might end up with lots of
discussion about these one or two word things...
BT: I'm afraid people will look at the points and NOT ask
"what's this mean?".
AF: This doc is a tool, so the people in this room are the
ones who need to understand what it means. Don't see it as a
high risk for this group accomplishing its goal.
Bryan Adamson, relaying comments on Jabber: Transport provides
an experience to the application. What about using the
application viewpoint to drive this? Also: part of the
transport experience is ICMP interaction. What about that?
AF: Yes, that is missing from the document. There is not much
about what the application learns from the transport.
Bryan: This is a deficiency with the current doc.
BT: One of the things we are realizing about the architecture
is take things that have been implicit and make them explicit.
We have this narrow interface to the transport. TAPS is an
opportunity to widen the interface a bit. Some of that came
out with the ICMP discussion on the list. We forget to ask
the question "What can I know."
AF: Maybe we don't have to do it protocol-by-protocol, but
there may be OS facilities to find out things about what's
happening? (Sockopts, etc.?)
Gorry: We talk about NORM but not FLUTE. It's probably more
deployed than NORM.
AF: We need someone to write text.
Vincent Roca: I will do it if I have instructions.
BT: look at NORM section.
Pete Resnick: "I have not written a useful line of code in
many years," but part of the problem is that this group can't
depend only on me and Stuart at the application layer. Used
to have an app that would put up a box that said "received an
ICMP notification" with a button that said "so what"?
AF: What's the right way to interact with that community?
Pete: Stuart, who's doing this?
Stuart Cheshire: my view of how it happens: some enterprising
person writes a library that they think does something useful
and puts it out there. Has to be well-debugged, otherwise
it's gated on that person's time to fix things and no one will
AF: What can we do to help that person?
Stuart: This is a potentiall fruitful approach (but not
happening): an application builds its own library that does
the set of thngs they think should happen. When the same set
of things gets implemented three times, the light bulb goes on
and maybe those get factored into a separate library. There's
been some of this, but a survey of the various "aspects" that
we want would be useful. Would be useful as guidance for
AF: I hear you saying this group doesn't really have the right
expertise, it's beyond the stuff we usually do - in other
words, there's deeper expertise elsewhere.
KF: How about ICMP - it's different v4 vs v6, quite a bit. Do
we need to onsider IGMP, ... other control/signaling
AF: We said "prioritize unicast" before.
BT: Instead of ICMP per se, we really mean "the ability to get
info about why something happened at the network layer."
Gorry: The list of things we really need to talk about in this
area is actually quite small - for most the application won't
know/understand it anyway. Are there more/others in v6?
Gorry: I am happy to work with anyone on that. Does anyone
want to help with that?
Gorry: When we get to the end of taps, we might just be
choosing from 2-3 choices. Even just doing that would be
useful - though it wouldn't please everyone.
Mirja: In the charter there is a mention of LEDBAT as an
example of congestion control algorithms that are in scope.
The doc has been ignoring "congeston control". Is it OK to
continue to ignore them?
AF: Not really. We wanted to to cover LEDBAT as an example of
a scavenger-type of congestion control that an application
might want. We needn't go into detail of the algorithm but
(as with the protocols) describe the features. Who knows
enough to write some text?
[MK raises hand, reluctantly.]
AF: I'll introduce you to the document editors. :) Again,the
goal is to mention that there are different kinds of
congestion control (as is already done in the doc), but it
doesn't need to e.g. describe LEDBAT in detail.
[Adjourned at exactly 15:00]