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

Meeting Minutes Transport Services (taps) WG
Title Minutes for TAPS at IETF-93
State Active
Other versions plain text
Last updated 2015-08-12

Meeting Minutes
minutes-93-taps

   TAPS WG Meeting
IETF 93 Prague
Thu 23 July 2015
13:00-15:00
Aaron Falk, WG Chair 

(Legend: AF = Aaron Falk, BT = Brian Trammell, MW = Michael Welzl,
MK = Mirja K├╝hlewind, KF= Kevin Fall, KN = Karen Nielsen, 

Agenda

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
interfaces.
	
	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
	the doc.
	
	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
	out.

	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
	3).
	
	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
want?  proposal:

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
meter, application-visible.

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
	document.
	
	[More arguing about terms. Chair allows item 4 on agenda to
	move up.]
	
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
	sufficient.
	
	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
	charter.
	
	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
	list.
	
	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
	protocol.
	
	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
	useful.
	
	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
the protocols?

	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. 
	KN: Right
	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
	other protocols". 
	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
	for TCP. 
	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
	alternative.
	
	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
	is OK.
	
	BT: Are there any objections if we back-out the rev of that
	section? 
	[no]
	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
	use it.
	
	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
	library writers.
	
	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.
	
	Stuart: Yes.
	
	KF: How about ICMP - it's different v4 vs v6, quite a bit.  Do
	we need to onsider IGMP, ... other control/signaling
	protocols?
	
	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?
	
	KF: Yes.  
	
	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.
	
	AF: (Time!)
	
	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]