[Taps] draft notes from TAPS at IETF-101 in London

["Aaron Falk" <[e-mail]>]

Here are the notes from the meeting.  Please send corrections or just 
fix the 
[Etherpad](http://etherpad.tools.ietf.org:9000/p/notes-ietf-101-taps?useMonospaceFont=true).

--aaron

-----

Transport Services (TAPS) working group - IETF101

Chairs: Aaron Falk, Zaheduzzaman Sarker

Note taker : Tom Jones
Aaron

Administrivia

- Blue sheets / scribe selection / NOTE WELL - 2 min
- Agenda bashing - 3 min

Agenda

1. Chairs update - 10 min

Michael W: There was security stuff in minset that I took out.

2. A Survey of Transport Security Protocols, 
draft-pauly-taps-transport-security-01, Christopher Wood, Apple. - 25 
min
         discussion point:
                 - updates since last version and review remaining 
issues
                 - revisit goals as they pertain to new TAPS charter 
text
                 - possible adoption as a WG item

Kyle Rose: In the proceess of working on this document there is 
something that is making me uneasy and I was speaking about it to aaron. 
It is about scope and scope creep, are we going to cover every security 
protocol? So, I am wondering if a better approach might be to choose 
enough protocols to analyse to cover the set of features that each of 
these protocols might have and then derive a set of shim features that 
are an interface to TAPS itself. If we try to go for everything we are 
not going to get this done
Chris Wood: I think looking at the implementations we will confirm or 
deny if we got the selections correct. If there are things that we do 
that are not in the standard that everyone does. I think that there are 
out standing issuses on the github tracker to add these new protocols. 
We could say for now to stick to the ones we have and maybe increase the 
scope a little bit. we need to be sensitive to time.

Kyle: We can go as far up in the stack as we want. There is envoy that 
uses these protocols in a sense. You want to choose a set of protocols 
from which you can distill out the fetures that a TAPS layer will need 
and which protocols that you need to support. TLS and DTLS are the same 
protocol at the record layer, but they differ.
	Chris: In theory I agree
Brain Trammel: In favour of adoption. The question about scope, I think 
we can go relatively quickly though the list of open issues and agree if 
we are going to get something into the set of charactaristics. RFC8095 
has a glaring issue and doesn't talk about gQUIC, but QUIC doesn't add 
any features. Two questions:
     one: post quamtum crypto...? I don't think that will change 
anything
		Aaron: is it deployed on the internet
brain: second: there is a split between handshake layer record layer, 
this is very TLS
	chris: in the crypto set document we reprhased everything.
	brian: it seems a very natural way to seperate.
aaron: great document. not sure if I am wearing my chair hat. To the 
question of which protocols to include, we need input from the security 
area. They might have priorities that we do't appreciate. The other 
thing is, will all these security protocols be considered behind the 
TAPS API? That's the way it looks from the diagram.
	chris: in practice we would go up to the TLS layer, higher is open to 
debate.
aaron: the goal is to allow applications on top of this thing. apps 
people might not have as clean as a seperation.
	chris: this is another area of the scope that is fuzzy
	Tommy Pauly: what protocols are in scope, we should limit to the types 
of things we have. they are providing a pseudo transport layere.
aaron: could you come up with a test to see if a protocol is in the set?
	tommy: Yes. we are considering security protocols that behave like 
transports
	kyle: we don't need to be exhaustive
zahed: the scope of the doc is explicitly not limited to IETF protocols
tommy: quic had an interesting discussion regarding the realtionship of 
TLS and the layering of the QUIC protocol. We have an analysis of the 
current IETF QUIC. If QUIC is in flux I am now sure how our doc can 
track it.
aaron: This isn't a critical problem.  We can complete doc and let it 
rest while QUIC matures. Then, we can revise our doc later to be 
consistent.
chris: the stream 0 problem they hope to have resolved by the next ietf, 
hopefully they will align
mirjia: quic, crpyto for quic is still tls. the handshake is the same 
the record layer si not the same.
chris: we need to review that text

3. A Minimal Set of Transport Services for TAPS Systems, 
draft-ietf-taps-minset-02 - Michael Welzl, University of Oslo. -10 min
          discussion point:
                   - updates from previous version

aaron: is there anything in the document that lead to a seperate 
discussion about security protocols
mw: there is text that references the security document.
aaron: do we think a minimun taps implementation must support some 
security protocols. this document is one place, the security document is 
another
briain: I think, we do need to say it is an implementation requirement. 
given the pattern of the rest of the documents we are putting security 
on the side. draft-wood seems to be 80-95 minset+security. minset should 
have a reference to the security document.
mw: which it does
aaron: In minset, we should say the minimum security requirements for a 
TAPS system are captured in the security document
kyle rose: a system using taps should have a minimum layer of security 
built into it. are we going to say transport protocols shouldhave a way 
to do security to be a taps transport
mw: there is away to derrive the minimum set, security stuff is the 
other document.
phillip; for the usage document we have a seperation between minset and 
usage for non security feattures, do we need the same for security 
features?
aaron: that one document will cover both
tommy pauly: the security set is much smaller than the transport 
features. if transport had come together more neatly we wouldn't have 
need the documents.
mirija: what is he plan for the decision tree
mw: it stays as an example
brain: previous conversation to reiterate, the three stage documents is 
because we didn't know the process before we started. we know how to do 
the process now. the security document can be faster.
aaron: sounds like we agree. sounds like we are done
aaron: shall we last call?

	hum:
	strong consensus in favor of moving draft-ietf-taps-minset to WGLC 
(none opposed)


mirija: shall we hum for the security document
tommmy: we couldn't before the recharter. shall we hum for adoption?

	hum:
	strong consensus in favor of  WG adoption of 
draft-pauly-taps-transport-security
	(none opposed)

4. An Architecture for Transport Services, draft-pauly-taps-arch-00, 
Tommy Pauly, Apple. -20 min (excluding discussion)
         discusion point:
                 - Design principles
                 - Terminology and concept definitions
                 - Applicability for charter milestones 3

5. An Abstract Application Layer Interface to Transport Services, 
draft-trammell-taps-interface-00, Brian Trammell, ETH Zurich. -20 min 
(excluding discussion)
         discussion point:
                 - the unified view (post sockets, NEAT, socket intents)
                 - concepts of an interface at the level of a 
language-independent, abstract asynchronous interface definition.
                 - relation towards taps proposed architecture (see 
agenda item 4)

Jonathan: are you assuming dns is async?
brian: yes
mirja: I am wondering why the properties are in the api document
brian: these are the things an application devleoper will have control 
over it depends on what the application implements.
mirja: are we assuming these are the mandatory ones
brian: not yet, these are common, but not mandatory
tommy: the implementation draft is focues on things that are hidden from 
the application, these are knobs to turn, but option to use.
kyle: a set of suggestions of things you could implement
mw: we should clarify these are optional for an app to use, but not 
optional to implement
brian: we don't have normative language yes. today we are asking if this 
is the correct approach. we need to back it up in the impl document

jonathan: it is not tcp acks?
kyle: it is not delivered
brian: if we have a protocol for this we might want to include it.

6. Implementing Interfaces to Transport Services, 
draft-brunstrom-taps-impl-00, Anna Brunstrom, Karlstad University. - 15 
min (excluding discussion)
         discussion point:
                 - implementation aspects
                 - relation to taps application layer interfaces

Lorenzo: does the candidate gathering occur in two different time 
phases?
tommy: there are interleaved
anna: conceptually there are different issues, they happen in parrell
colin perkins: one of the open issus we have on this draft is resolving 
all the issues, nat traversal, happy eyeballs, ice...

colin perkins: to clarify, for udp one of the open issues is to 
integreate with things like stun. we are aware there are details missing 
at this point

jonathon: you are forbidding half close
anna: there is no functionality in the api
tommy: a close is interpretted as a termination. we are still discussing 
a half close. it is sending parameter, not a termination parameter

7. Combined discussion slot for agenda item 4,5 and 6. -30 min
         discussion point:
                 - see agenda item 4,5 and 6.

aaron: the most important thing I want out of this discussion is whether 
or not to adopt them:

     hum:
	    in favour: strong hum
		  oppoosed: silence
		  need more information: silence
		
aaron: OK, let's have a technical discussion...

kyle rose: the section in rendevous, there is an intent for rendevous to 
be very general. we are going to want that, it is not just dns but 
sevice discovery by a database
brain: we know that and we need help
michael tuexen: two commmenso n send. you had ttl on partial 
reliablilty. you had ataomic send. I agree there is a need to provide 
the send call where a message begins and where a message stops. it could 
be limiting to do atomic sends which limti the size of the message to 
the size your stack can handle.
brian: there is a notion of partial send and partial recv. if the lower 
layer cannot find end of frame before end of buf you will get a partial 
recv
mt: I will provide when it is finished
brain: a stream looks like one long message
tommy: it os the smae for the send. feedback on naming would be good. 
for a while we had content as the piece of data that you can send, 
related to the larger overall message. we have changed the wording tobe 
more message centered. there are properties of that message seperate to 
the sending data.
colin: rendevous, the inital goal is tosupport he and ice. once we have 
that we generalise it to anything else. it is fairly clear there are a 
bunch of terminology issues. suggestions welcome.
tommy: on rendevous if when looking at use cases if you see things that 
are limited by the current architecture please bring these up.
colin: we are aware we need app level help with these.
zahed: without chair hat. Policy, arch draft saysa there is a system 
plicy, but there is nothing in api, impl says we have multiple policy. 
Rename system, or api to include more on how to install polices.
anna: there is some inconsistency in the naming
tommy: api draft is about the interface provided to the application 
developer. there is missing language about the api for a sysadmin, this 
is an oversight. app isn't going tobe setting system policy. we should 
add something about an administravie interface
anna: there are different timescales on these things.
zahed: you have priorities between different policies
tommy: the architecture puts these in implementation concepts. the 
classic example is on a phone blocking using cellular data. the part of 
policy to interact is path selection properties.
zahed: applicaitions need to say something about the policy that the 
system should listen to. I am asking for clarification when you have 
multiple policies active.
anna: at the moment we only have the constraints you have to follow. in 
practice it is more complicated and you have trade offs. some is imple 
dependant
jonaton: first it is better to say these are read only to the 
application not invisilble
brian and tommy: yep
jonathon: the one event I didn't see is tcp low water. is it okay for me 
to send
tommy: this was brought upin the discussion. we are trying to avaoid 
this, it is a propety of how you interact with the socket
jonathon: not that specifically
tommy: this is the point of the callback. we have this in public apis 
already, don't enquque before you get teh call back
jonathon: it would make you more confident if you were eating your own 
dog food. could you implement quic on top of this or ice or rmcat
briain: we have a plan for research on this in go, quic and tcp in this 
api
tommy: at apple we are using this internally and for our own prototpyes 
for quic interop
praveen: in terms of service, apps wanting lower latency higherthoruhg 
put. in terms of those is there anything in this api. socket api cannot 
provide intent
phillipp: laughs
theresa: right now we have the capacity profile, low latency or high 
bandwidth. we have intents 'this is a big transfer' the app wants to be 
as precise as possible. we need to figure out which properties to 
include
brian: all that right now is an appendix on the interface doc. 
everything we didn't have concensus on what went into the appendix
tommy: these are elements we have finalised the semantics for. look at 
the appendix, open an issue on the ones you think are important.
praveen: real value, that is what is missing. the abstraciton is great. 
some sort of consistency guarentee would be useful
tommy: for deployment it is important that the preferences can take this 
into account.
praveen: my question is different. if you did racing and end up with x 
the app would prefer to keep picking that
brian: there is chunnk of the arch we didn't talk about. the security 
state cache and transport state cache. any implementation will have to 
learn about paths. we can reccomend parameters. you need this cache to 
make it work.
tommy: in he we already do this, we are stick to addresses we have done
gorry: on policy, there are multiple viewson what we have as inputs. 
some are predictable and some are optimisation and tuning. I am also 
concerned if we do everything we end up with a gaint spec.
tim chown: the sysconfig you pull these from is a bottomeless pit. pvd 
in intsrea is something interesting to me.
brian: it sounds to me like there is a collection of things people 
wouldlike to see. maybe a fourth doc. there is ahole we need to consider
aaron: yes, we can't write it yet

aaron: do you have a thought on cohabitation with applications that have 
needs for more granularity from the api
anna: part of that is protocol specific properties.
aaron: does taps have to implement that.
brian: no that won't work. this is tided to an issue we just noticed in 
london. the interface document is the low performance version of the 
document. We probably need to get out of the way for batch and memory 
mapped io. we need holes in the api
aaron: we have focus on simple should be easy, can complex things bipass 
taps?
tommy: my gut is that it should all go through taps. we cannot be worse 
than existing standards. if all you do is allow someone to setseockopt 
you expose that there is a socket there, which exposes things that might 
not be true. have a mapping to important sockopts and have a mapping
aaron: doc should say this

thersa: about properties, we have a zoo. required, preffered, can be 
quieried. I propose we make one section in api where we sort this out.
phillipp: the taps system should have some auto mode where an app 
specifies in an easy way "i am doing stuff, give me appropriate 
transport" on the other hand allow the app to ask for precise transport 
protocols with set properties. An app can mix and match with these 
modes. How exactly to specify what I am going to do.
tommy: I agree. It is really not diverging from what socket applicatons 
do today.
colin: this api is being built on our best guess of what it should look 
liike and our protocol experience. It would be good to get WG input on 
protocols that do not fit with this api.
aaron: multicast
colin: yes multicast, and maybe icn. If there are styles we should have 
the discussion.
aaron: taking the documents as working group items should not fix the 
set of documents we work on
aaron: I am going to assume WG adoption, we will confirm on the list

brian: the authors put together a github org. do we want to bring that 
under WG control.


8. Problem Statement Regarding IPv6 Address Usage, 
draft-gont-taps-address-usage-problem-statement-00, Fernando Gont, SI6 
Networks. - 10 min
         discussion point:
                 - whether the topic is of interest for this working 
group
                 - possibly adopting the I-D as working group document

gorry: I see two things in the document. Something about use of ipv6 
addresses and policy and I see the need for a new api if we need to 
react. I am interested in how 6man felt about privacy and use of 
addresses. Maybe it shouldbe two documents. What happened in 6man?
fernando: I presented twice, reponse was in belonged elsewhere. myself, 
the properties might fall into 6man or int area. the api is something is 
more clearly in taps
ole: in 6 man we defined these mechanisms for generating addresses with 
these properties. we have specifed one document on source address 
selection with policy tables and ways for applications to make 
preferences for which type of address. we are very much bottoms up we 
made it available without an idea how it should be used. which is why we 
wanted to drop it to the people that can make use of this.
tommy: there are two seperate concerns. tha aspect of privacy and 
security, when to use one over the other belongs in another document 
which isn't in taps, maybe int area. however the mechanism for selecting 
these is a taps arch selection property. as a server what source address 
do I want to bias towards. this is all very relevant, the right place to 
specify would be in the interface. rather than adopt, what if we add 
this to the taps api?
ferndando: for me that is fine. I agree there are two parts. the anaylse 
of the properties is neccessary to do the other part. what I wonder is 
where do you keep the analyse, the api could belong in a different 
document. some place or another you need a disucssion on mapping 
addresses.
tommy: it would be useful to reference that document. also what should 
the taps system do for default, listener vs outbound.where?
aaron: I don't think it is us
theresa: I see potential input to the impl draft. I see relationship to 
the security params in the api draft
gorry: is it possile to revise the draft to make it clearer between the 
api and the problem space. this would really help me figure out who 
should look at this. an api section should be in taps, the other section 
needs someone looking at it.
fernadon: forthe api we have a problme statement, but no api
gorry: talk about the api implications in a seperate bit to where you 
talk about implications
tim chown: I thin the bulk ofits should happen here. 6774 says this 
should happen for out bound, pvd may change this.