Editors:
Kyle Rose
Jake
Eric Kinnear
Brian Trammell (second rhythm guitar)

TAPS
IETF 104 Prague
FRIDAY, March 29, 2019
1050-1250  Morning Session II
Minutes

1. Agenda bash (2m)

2. WG update - chairs (5m)

• Gorry: rev I-Ds after interim with changes as discussed
• Use Github for meeting materials?
  • Mirja: In the datatracker speakers can now upload slides directly and chair only has to approve. Therefore less need to collect slides on github first.
  • Brian: QUIC uses it for nearly everything (e.g., slides)
  • Aaron: Likes the idea of minimizing process: let presenters upload their own slides, etc.
• Github Logo
  • Brian: I uploaded a nice logo shamelessly lifted from the Austrian Post
• Security draft: WGLC?
  • Discussed (Kyle, Aaron, Mirja, Tommy). Rough consensus among commenters was that this draft (like minset and the original survey) is input to the main drafts and so should be frozen before them. So WGLC very shortly.

3. How should we do framing? - Tommy Pauly (20m)

• Jonathan Lennox: Is TLS a framing protocol? A: Let's get back to that.
• Brian: Is RADIUS a framing protocol, or the TLV encoding a framing protocol? Etc.
  • Tommy: The part that does the encoding. HTTP isn't a framer, but the way you encode headers and body are.
• Kyle: Seems like 1:1 should apply to transactions, as well: don't want a framer to result in multiple transactions between the client and server.
  • Tommy: Framers can hide additional control traffic, e.g., ping.
• Aaron: Want to be able to run framers on one endpoint and not on the other. I read this as something that chops messages into frames and sends them to the other end where they can be interpreted either with a framer or without. Why do I want this other protocol under there? I just want to chop up my message and send it to the other side.
  • Tommy: This layer is used by the application to parse out the payload stream and transform it into something more useful for the application.
• Ted: Concerned that we're adding in-exchange signaling that would be surprising behavior for an application.
• JL: The name "framer" might be confusing for this, suggest we might want a different name.
• JL: A framer might be a good way to implement STARTTLS.
  • Tommy: We want TLS as a first-class function provided by TAPS because we want security wherever possible.
• Philipp:
  • reliability/multiplexing might not be preventable in framer context
  • Tommy: stack/connection can push back, you can shoot yourself in the foot though
  • p: it's complicated and confusing
  • tommy: make good choices and you're ok. this is the checklist.
• Brian:
  • This should be called the presentation layer. (Bikeshedding)
  • Stick "defining framers" slide content into the architecture document
  • Not clear how much of this surface belongs in the implementation doc vs. architecture doc
  • Let's try to come today to "is this okay? Does this make 
• Kyle clarifying:
  • You can make a transform between wire protocol and whatever protocol is easiest to use for the application. You want the application to be able to use an interface that makes sense for their business logic and then transform it to match whatever it should be on the wire. 
  • Tommy: We should add some guidance, but an application that defines these itself it shooting itself in the foot if it defines the wrong thing

• • For example, Unicast DNS runs natively over UDP, but when running over DoT or DNSCrypt, define a framer that gives you the transformation that allows DNS to go over DoT

• Colin Perkins: Timers and framers runs risk of opening up complexity

• I'm very supportive of the concept, although I agree that we need to bikeshed the names and details. The comment in slide 11 about "timers in a framer" runs the risk of opening up complexity, and we need to think carefully about the scope of the API. Also, need to make sure the abstract API we design doesn't accidentally preclude zero-copy implementations.

• • Tommy: I know
• Ted: You don't actually always know what the wire format of the real application message is going to look like until the first few parts of the exchange are finished. Doing a framer makes it harder for them to treat TAPS as just a base transport. Think about whether this is structural or just implementation advice for people who are going to run applications over TAPS
  • Tommy: Can you write up a paragraph and send to the list for issues around DNS
  • Ted: Will do
  • Tommy: VPNs, for example, we've got the ability to do NAT-traversal, TCP transport, etc. and it's simple to swap those out 
• Philipp: Choice of framers might impact protocol selection.
  • Tommy: The framer must correlate with the protocol stack.
  • Need to choose framers at the same time as racing because they're specific to the entire protocol stack.
• Aaron: So I think we've invented layering. This looks like an architectural concept that says you can layer on a framer. UDP, IP?
  • Tommy: It was already invented for us. We are not going to ask applications to implement UDP/IP. The stack can provide built in framers. Difference between implementation details of what needs to be composed, vs. application controlling the shape of the framing that it controls
  • Aaron: Name "framing" is distracting from the problem that needs to be solved. I'm still very confused about what the architectural invariant is that this concept is adding. What's different vs. me just being able to take whatever protocols I want and compose them? 
  • Tommy: We're not reinventing protocols. TAPS is about protocol stack agility, for example IKE uses ESP, UDP encaps, TCP encaps. Without framer being available in the architecture application needs to have 3 ways to do everything. With this, we can just switch between what's happening underneath.
  • Tommy: Built into the TAPS library, saying that we can fall back between different options and apply a transformation so that you can still use messages
• Lars: You've just reinvented Touch's & Day's recursive network architecture
• JL:
  • There's a lot of stuff that could be modeled as a framer, that doesn't mean the implementation should expose UDP as a framer the application could insert.
  • There are other things an application might want to be able to insert (e.g. a web proxy) that aren't framers; but let's leave those for TAPS 2.0.
  • You're going to need the ability to have the framer be able to push back data that was already read, in case it went too far. That could be useful in general, you could pass that to a different function. 
  • Tommy: That would be a good thing to discuss more in detail
• Gorry: I'm not convinced yet that we should be digging into a lot of this. Something vague could be better. We need more implementation experience from different people. Let's figure out how much of this should appear in the API.
  • Tommy: I think it should be present in the document. Relatively minimal, but accurate. We've implemented this, and done almost a dozen protocols over framers. Let's talk about what is useful and how it's useful, what's the minimal set that can be defined.
• Michael Welzl: Can we agree that signals are not of concern to TAPS but to the application? If not, then all that is left is framing. (I.e., everything is framing.)
  • Brian: I think that's my goal as well, new arbitrary signalling here gets rid of the single picture for the application. That breaks down if the signalling itself changes the arrangement of framers, like STARTTLS. Shooting yourself in the foot should hurt a little bit. 
  • We don't want to be in a place where it's unclear that you should do arbitrary framing in the framer, we need to not lose sight of what the goal is. 
    • <Brian, is this the meaning of what you said?>
  • Tommy: The balance is between the purity of the architecture and what's the minimal amount needed to get practical stuff done. 
  • Brian: Can we get rid of timers? That scares people
  • Tommy: That's fine, we can do that

(+17 mins agenda time)

4. Connection Pools for HTTP-like Protocols - Philipp Tiesel (10m)

• Michael Tuexen: clarifying question: all connections in pool go to the same endpoint?
  • Philipp: Go to the same endpoint as specified, which might be the same server or not, depending on how server discovery is implemented
• Michael: What is SCTP one-to-many?
  • Single socket, for multiple connections.
• Tommy: Could be layer above TAPS. Definitely prefer the second type of approach. Rather than a property of the connection, it is a property of the protocol. Most of the text here belongs in the implementation. It really is an immplenmentation detail.
• Brian: I don't think that putting this in the interface gives the application any control that we can't expose via transport properties later. Pooling things on the client side in the presence of some load balancing architectures in use is probably not a good way to design an interface we want to use for the next N years. Was sure I was against it before, still against it now, but there are implementation techniques that could be useful.
• JL: TURN: one connection to a TURN server, but present it as multiple connections to peers.  Is that this, or is that the inverse of this?
  • Philipp: I think the inverse
• Eric Kinnear: Interface here becomes a little trickier. Not sure how it should be expressed. Second PR gets us closer to how we want to express this in the interface, because an application really only cares about sending a message and getting a response.
• Jake: Agree with Brian + Tommy, idea becomes a lot more interesting when you look at the connections that are established. Tricky, don't want to do it here, but we could do something with respsct to application visibility into pooling. 
• Aashu Singh: Does the connection pool take different CC on different streams into account?
  • Philipp: Really good question... Implementing this with respect to CC is complicted, goes into racing, path selection, flow control. Happy if we can do the first three on slide 4/
• Kyle: THis works well for stateless uses of HTTP. Not for state-modifying. Binding to server and ordering matters a lot. Would be useful for any stateless protocol, not just stateless uses of HTTP.
  • Philipp: Yes
• Aaron: Editors have said that this isn't a great idea. Should we take a hum?
  • Philipp: If you don't like it, fine to just close the PR 
• Conclusion: If there's anything, it'll be in implementation. New text to come in implementation

5. ETH Implementation Report - Brian Trammell (15m)

• Main point: Being able to express TAPS in idiomatic ways for languages and other project architectures makes a big difference in ease of adoption and implementation.

6. TU Berlin PyTAPS Implementation Report - Max Franke (10m)

• Tom Jones: Did implementation draft help, feed back, time to work on this?
  • Yes, yes, and yes.
• Tommy:
  • Are there more Pythonic idioms that we could use?
    • Max: Nothing in Python is immutable because nothing is private
  • Open an issue for each of the bullet points on Github. Would be nice if unclear things resulted in changes to the doc
• Eric Kinnear: Thanks for doing this, looking good. Re: specifying protocols by name/identity vs. the properties, it's valuable to have the underlying stack speak solely in terms of properties, but the rest of the internet has been talking in terms of protocol identities. To that end, the interface can specify convenience setters that map the protocol identities to the properties they have, so the user of the API doesn't necessarily need to keep track of those, while people who do want to keep track can do so.

7. Proposal to Create a YANG Model - Jake Holland (20m)

• Basic idea: Portable config enables a bunch of cross-implementation ease-of-use, such as test suites that can be used to validate implementations.
• Jake: Can I just throw this over the wall?
• Brian: "Drive-by YANGing"
  • All ready to buy this until you said you can generate Java code out of it. Haha.
  • Really cool. Opens up many avenues for confusion because YANG is well-known in the IETF for configuration data models. There are other entrypoints for things that aren't *really* config. There's what you *can* do with YANG, and there are a (smaller) set of things that it's good for.
  • Jake: We're configuring connections.
  • Brian: I hate the conventions used in the interface doc and I wrote them. Seems more useful as an appendix to the interface draft. As a separate doc, it might get out of sync.
• Tommy:
  • Important to have rigor at the current maturity level of the main docs.
  • Is YANG the right rigor model for TAPS?
  • What do we do with this work? "How am I supposed to use this?" Put this up into the WG Github as a kind of conformance test. Essentially: be able to do a sanity check. Express these configuration variables and see if the API does the right thing with them.
• Michael Scharf:
  • Value of looking into YANG, but...
  • If the problem is the model of the API, it might work, but that's not what it was meant for. YANG and YANG tooling are very specific for configuring network elements governing operational state.
  • YANG is not the natural choice for all use cases. Other solutions and other data modeling languages might be better for typical TAPS use cases.
• Mirja: This is not a model for the interface, but rather for the preconnection configuration.
• Jake: If you have suggestions, please offer them.
• Michael (Scharf): Make an informed choice.
• Gorry: Thanks for the rigor, +1 on concerns for putting this into the appendix, because this is not what we're really about. This isn't what TAPS is about, but it's YANG about TAPS. Don't embed YANG by accident. Presentation question, prefer a separate draft.
• ???: not sure how to do that.
• Gorry: Publish together, make them go through as a pair.
• Mirja: Really like it as a way to share properties for a connection and test it out on other systems. But also something you can just do on top of TAPS. The value of having it right now is to double check if it works. But don't need it as part of the spec now.
• Aaron: summarizing consensus, this is a useful tool but we don't want to confuse people. Question about long-term or short-term interdependence of drafts.
• ???: As inmplementor I want something solid to work on
• Aaron: Michael said look into other languages for rigorous modeling.
• Tommy: Re: keeping things in sync, every time you do a commit that modifies the model, you need to update the model as well. Maybe not YANG, but some other data model spec. Keep everything in sync using Git hooks etc.
• Aaron: Who's going to look at tools?
  • Deafening silence
• Michael (Scharf): I can try to send something to the list. What I am aware of is not specifically for this use case.

8. Using TAPS for Multicast - Jake Holland (10m)

• Gorry: Do you need source filters? Doing ASM and SSM, but there's an intermediate bit.
  • Jake: Not sure. Need SG Joins. Do I need a full source filter? I hope not. I don't have that use case.
  • Need TTL and sender? Yes.
• Tommy: SSM vs. ASM is a property that belongs... where? Could it be a property of the endpoint? If I have a multicast "connection", where do you envision that property being?
  • Jake: Receiver needs to be able to set that as a property of the join.
  • Multicast *is* in scope for the work we're doing. This is the time to add it to the docs.
• Brian: Have been punting this for a while. Post-sockets multicast was very naïve. Could be an alternate set of APIs into a connection, but this seems like a different kind of thing. Review the problem description in #150, and see if it still matches our understanding of the problem space.
  • Jake: I want to make sure I can do UDP. In the TAPS scope, we should make an extension to do fluid and norm(?) and RTP.
• Max: Possible to implement it pretty easily in our implementation.

9. AOB?

• Aaron: Try to agree on a date or week for interim?
• Tommy: Implementation document direction should be discussed at the interim. Rev before the interim, or create PRs, discuss them, and then rev after?
• JL and Gorry: Both is good.
• Aaron: Both is good if we don't need an interim meeting first to decide what to put in the rev. April or May? Everyone said May. So we'll do May. Week of May 13th?
• Brian: End of week is bad. (IAB boondoggle at end of the week.) Beginning of the week is good.
• Colin: Avoid that week.
• Aaron: Monday May 6? Seems fine.
• Not a hard "no" for Brian.
• Aaron: Time? 8 am PDT, 11 am EDT, 5 pm CET.
• Colin: May 6 is May Day
• Aaron: Wednesday May 8, same time.
• Gorry: Interim is open? Of course.

INTERIM: Wednesday, May 8, 8 am PDT, 11 am EDT, 5 pm CET. 2 hours length.

FIN