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.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
