* 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, Magnus Westerlund | 2014-Sep-23 —  
Chairs
 
 


IETF-105 taps minutes

Session 2019-07-22 1330-1530: Van Horne - taps chatroom

Minutes

minutes-105-taps-00 minutes



          Transport Services (TAPS) Working Group
          13:30-15:30 Monday Afternoon session I
          Room: Van Horne
          Chairs: Aaron and Zahed
          Jabber: Theresa
          Note-taker: Gorry Fairhurst
          
          Administrivia - Aaron & Zahed (5m)
          
          Minset ID is waiting on draft-ietf-taps-transport-security (MISREF).
          draft-ietf-taps-transport-security will proceed to WGLC write-up, and
          Philip agreed to shepherd.
          
          September Interim was sumamrised (see notes).
          
          Framing - Tommy Pauly
          
          Mirja K - Do we ever need to stack multiple framers.
          Tommy - We could potentially have a framer for one thing (e.g. DNS)
          that works over another. 
          Mirja - That's more an implementation question rather than an
          architectural question.
          Mirja - Why do you need to add the framer to the preconnection?
          Tommy - You get a connection, and the framer starts at some unknown time.
          Mirja - Do you need it in the startup? Do we need to have the start venet?
          Tommy - Yes, that's useful. The start gives an opportunity to add
          memnory, etc.
          Colin P - These are things if you are building a framer, not the App?
          Tommy - Yes. 
          Colin - I thought framers could be implicit. (e.g. adding one when http
          is used).
          Tommy - Yes,for a lot of protocols that are framed.
          Philip - Can we implement starttls using this?
          Tommy - Yes, by prepending a framer after the preconnection.
          Aaron - Do you still belive when using TAPS with a framer that this can
          be one-sided?
          Tommy - Yes, nothing appears on the wire.
          John - Is the TAPS model different to Applenetwork frame?
          Tommy - Preconnections = parameters for us.
          John - What about multiple preconnections?
          Tommy - They refer to the instances that are created, rather than creating
          an object and instantiating it.
          Theresa - One of one possible way to implement one part of a protocol
          (i.e. a set of functions). Should we
          separate the transformation and the buffer management.
          Tommy - Can you open an issue?
          
          Erik K - I like the framer view of the model. It could do a handshake
          if you like, etc.
          Philip - It got easier for me to understand if I think the framer is a
          buffer manager. Is the API focussed
          on the buffer management, rather than how to compose the stacking.
          Tommy - The data path does involve buffer management. Do we agree the
          functions exist in the current form?
          Philip - I think there may also be other ways to implement ba framer.
          Tommy - The question relates to how portable the parts are.
          Theresa - I suggest keeping how to add a Framer to a Preconnection and
          the set of functions a Framer can implement in the API draft, and moving
          "how to implement a Framer" to the implementation draft or maybe even
          a separate draft if this grows out of proportion.
          Max +1 - there are implementation-specific details that vary by
          language. There are many implications.
          Colin - I agree with Theresa, it's better in the implementation draft. We
          should describe what it does as a parser or serialiser.
          Brian +1. Message framers are not protocols. 
          Colin - We could in the implementation sketch the approach for different
          languages.
          
          Property Profiles & Explicit Protocol Selection - Michael Welzl
          
                  •     https://github.com/ietf-tapswg/api-drafts/pull/328https://github.com/ietf-tapswg/api-drafts/pull/327
                  •     Do we really (still) have any resistance to this idea?
          
          Brian: What is "allow" a specific protocol, or implementation specific
          protovol
          one reason a lazy developer
          Gorry - There are cases where someone absolutely needs to do this - an
          emaple is where there is a signalling protocol that needs a protocol,
          port, etc top be set up.
          Colin - If we build a general purpose networking API we need to be able
          to do what people need to do this. The stack should make the default easy.
          Tommy - Should allow you to specify a protocol.
          Anna B - I basically agree, when you wish to write an app in TAPs,
          and in the future you get TAPS benefits - but at the moment
          Mirja - We should make it hard.
          Theresa - Use profiles is an easy way to get the right outcome and to
          discourage some applications from picking a specific protocol.
          Brian - We should help make it a bit more discouraged - use a blank tag,
          don't do this. I reviewed both PRs at the same time and was confused,
          since they seemed like opposing PRs, can you explain
          Philipp - (explains the 2 ways that you can use profiles to help/force
          the protocol that is selected) 
          Brian - I don't dislike the idea as much as I thought I would.
          Keith - IMO it is absolutely essential for apps to be able to specify
          transport protocol(s). My experience is that there too many subtle
          differences from one transport protocol to another, to expect apps
          to run successfully over arbitrary protocols.  Second, by permitting
          arbitrary transport protocols you make testing of apps and support into
          nightmares.   It's one thing if a app can support (and is tested on)
          N protocols (for small N) and that's potentially useful, but arbitrary
          number of protocols is unworkable. 
          Using profiles is inviting more variability between endpoint situations,
          and more ways for an application to fail in mysterious ways
          Zahed - Thanks for this discussion. When do we need a protocol? (something
          only working with one protocol). An app devceloper wants to use TAPS to
          get the best set of services.
          Colin - We are building an API for the longterm. This is intended to be
          the only future API. We need to be able to explicitly request a protocol,
          that is still a reasonable case. 
          Michael - Can we add a profile with just one protocol specified.
          Tommy - I don't like the profile we say what we currently do, and I
          think this is a convenience. I think it will depend on use-cases. A
          Yang model could have details that let you do everything, but that's not
          interesting to be a part of the API. I think this is more about what we
          do in the future.
          Aaron - I think Keith's point is that apps need to be able to specify
          completely what happens.
          Tommy - I think we can limit what is exposed.
          Philipp - I think we need to be able to set the protocol and set the
          properties. We talked about the defaults - we can specify default
          profiles. You can add to these profiles, but you eliminate the problem
          that we have to agree on one set of defaults.
          Mirja - On selecting a specific profile.
          - A specific stack
          - A test case
          I didn't see why this is required.
          I think profiles should not be in the API
          Michael S - There are protocols that use specific protocols and specific
          parameters. There are real uses-case that need specific params and
          protocols. One example will be discussed in the TCPM session during this
          IETF meeting.
          John - I argue that in the future apps may start doing things because
          TAPS chooses some ways, we need to avoid protocols coming on line becaue
          a stack is simply updated
          Keith Moore - As an app developer I would love to be able to find out
          what options exist to connect to a peer.   That doesn't mean I want  a
          lower layer to choose an arbitrary stack. *and not just legacy protocols*
          Theresa -  I want to make the stack easy to use, without needing the
          details. Profiles make this a cleaner thing to explain, even if the
          profiles are in an appendix.
          Phillipp - Can profiles be a parameter?
          Anna - I would not want them as a parameter.
          
          Should profiles be in TAPS?
          Humm for inclusion in taps (none against) - TAPS seems useful.
          
          Should this existance appear in the API?
          Humm for inclusion in taps (some against)
          
          One possibilty:
          (1) profiles are 1st order and specified (2) In the appendix and how (3)
          We could place this in our own document (4) Could be in implementation.
          
          Tommy suggested this:
          (1) profiles are 1st order and specified - essences in  (2) mentions
          they exist and give an example In the appendix (3) No mention.
          
          - The WG will ask Tommy to form this question and ask on the list
          
          Parameters & Defaults - Michael Welzl & Philip Tiesel
                  •     

                  •     Should we specify rather than recommend default values?
                  •     https://github.com/ietf-tapswg/api-drafts/pull/317
          
          Gorry - are we following the examples set by other IETF work? What do
          you want to see?
          Gorry - I was happy that the policy could be overwritten
          Eric - Is the default that I must specify this unless the client overrides
          it? (yes) We've seen different platforms have different defaults -
          is this going to be any more effective if we say MUST?
          Mike - We should have SHOULD for these cases where it could be different
          for different platforms
          Brian - ... your reason for filing the issue was that the language
          was too loose. An alternate suggestion: the default IS .... -let's use
          that language
          Aaron - confused by the discussion - we agree that there should be
          defaults. It's less loose than what we have
          Gorry - Yes - we avoid the lowercase "recommend".
          Mirja - We shouldn't use normative language
          Gorry - I wanted to use normative language because there were reasons
          to do that - because the base RFC that said this required a certain
          behaviour. We should not be wooley or even contradict the RFC series. I
          am really content with "The default is".
          Keith - Please define things in such a way that applications behave
          predictably across different locations and different hosts. If defaults
          are implementation-dependent, I don't think this happens.
          
          ARCH & API open topics - Philipp Tiesel
          
          issue - Listening filter behaviour 
          
          Tommy - We decided not to do this when we did our implementation. I may
          want to do something before an app starts. i.e., something that says how
          many conncetions to accept that is TLS-specific, e.g. to reject all from
          a subnet.
          John - I think you should be able to respond in a different way.
          Brian - I think we need to look at this again. I retract statement on
          resolution A - it's beautiful, but not practical.
          We need to respond to back pressure and early rejection.
          We could add a new event.
          
          Issue - Multicast
          
          Jacob - There were things done in the Hackathon.
          Gorry - We could do more, but we should do the least, I like what
          was done.
          
          Issue 249
          - we need text, can be closed.
          
          Issue 307 - selection configuration.
          Theresa - I like the initation error to include a reason (b), we need
          to know which failure mode, but can't foresee all in the API document.
          Brian - I am confused. A bad initiation should fail at call time. 
          Tommy - Initiate does not have a return value. 
          Brian - I think resilution (b) is good.
          ?
          - All error events could include additional events.
          Tommy - I like fewer events with more descriptive errors returned. One
          event is much easier for the app to catch.
          Max volunteered to work through this topic.
          
          Issue 334 - padding
          Erik - May be sueful for apps.
          Gorry - if we have PMTU info this can be useful. It can also be a really
          stupid thing to try to do.
          Mirja - we could do other stuff.
          Brian - There are things that we may want to tag in the git hub to be
          future work.
          
          Issue 336 - message context
          
          Tommy - Is the returned value only the context that was supplied?
          Philiip - Yes. 
          Tommy - Let us just pas sthe value that you want to use.
          Michael - just query the transport system and ask what was chosen.
          Brian +1
          
          Do you get lots of send errors from the same send? (ofr each send you
          can potnetially get a send error)
          Colin - We do not need to specify.
          
          All the rmaining issues will be posted to the taps list to try to seek
          resolution asap.
          
          YANG Model - Theresa Enghardt
                  •     Benefits and pain points of using Yang within our PyTAPS
                  implementation
                  •     Suggested changes to the model we come up with during
                  the hackathon
          
          Tommy - Thank you for doing this. Feels like where the profiles ideas
          could fit well. We also discussed how we test the output - we could try
          to expose the decisions - the other alternative is to have a server and
          then orchestrate this on the server to accept different combinbations
          of protocols.
          Mirja - I was more convinced that profiles and yang models were different
          ways to do this. 
          Aaron - Yang models are a way to describe profiles. This helps apps
          choose useful sets of behaviours, so apps developers do not need to
          think about that.
          Mirja - You could just publish a set of yang models.
          Thereas - I dont think apps developers need to read yang models.
          Mirja  - You would need several yang models - I think profiles would
          be much simpler.
          Jake - are you suggesting we have profiles in the yang model or just
          define features? This can make the yang model less useful. It is easier
          to specify profiles for app developers.
          
          Next meeting: September 2019  Virtual Interim.
          
          



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