* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Taps Status Pages

Transport Services (Active WG)
Tsv Area: Mirja K├╝hlewind, Spencer Dawkins | 2014-Sep-23 —  

IETF-101 taps minutes

Session 2018-03-21 0930-1200: Park Suite - Audio stream - taps chatroom


minutes-101-taps-00 minutes

          Transport Services (TAPS) working group - IETF101
          Chairs: Aaron Falk, Zaheduzzaman Sarker
          Note taker : Tom Jones
          # Blue sheets / scribe selection / NOTE WELL - 2 min
          # Agenda bashing - 3 min
          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
          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
          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
                          - 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
          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:
                      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
          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.

Generated from PyHt script /wg/taps/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -