Minutes IETF101: taps
minutes-101-taps-00

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 features 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 rephrased 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 don'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 layer.
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 mirja: quic, crypto for quic is still tls. the handshake is the same the
record layer so 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 minimum taps implementation must support some
security protocols. this document is one place, the security document is
another brian: 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 should
have a way to do security to be a taps transport mw: there is away to derive
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
features, 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. mirja: 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)

mirja: 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 developer 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 focused 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? (refering to Sent event after sending a message)
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 parallell
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 interpreted 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
                  opposed: silence
                  need more information: silence

aaron: OK, let's have a technical discussion...

kyle rose: the section in rendezvous, there is an intent for rendezvous 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 commments on send. you had ttl on partial reliablilty. you had atomic 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 limits 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 same 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 to be more message centered. there are properties of that
message seperate to the sending data. colin: rendezvous, the initial goal is to
support 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 rendezvous 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
says there is a system policy, 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 to
be 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: applications 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
up in the discussion. we are trying to avoid 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 enqueue
before you get the 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
prototypes for quic interop praveen: in terms of service, apps wanting lower
latency higher throughput. 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 chunk 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 recommend 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 giant 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 would like
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 bypass 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 setsockopt 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

theresa: about properties, we have a zoo. required, preferred, 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 like 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 should
be two documents. What happened in 6man? fernando: I presented twice, reponse
was it 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 analysis of the
properties is neccessary to do the other part. what I wonder is where do you
keep the analysis, 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 possible 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: for the 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 think the bulk of it should happen here.
6774 says this should happen for out bound, pvd may change this.