Transport Services (TAPS) working group - IETF102

Chairs: Aaron Falk, Zaheduzzaman Sarker

Note Taker: Theresa Enghardt (and Kyle Rose)

Administrivia

# Blue sheets / scribe selection / NOTE WELL - 2 min
# Agenda bashing - 3 min

Agenda

1. Chairs update - 10 min

2. Taps drafts publication track selection ? - 10 min
        discussion point:
                - which publication track should be selected for architectural, interface and implementation drafts?

Spencer: The IESG was also surprised by the "does not represent an Internet community consensus" bit. 
Kyle Rose: No mention of the word normative? 
Aaron: Normative would be standards track.
Kyle: Lots of normative language in experimental. Informational drafts seem to describe the state of something. But they can also have normative language.
Aaron: I think this should be standards track. There's multiple implementations. We don't know if it will be popular. I don't think Experimental applies here. But counterargument: I don't think we should standardize APIs.
Mirja: Informational does not HAVE TO represent community consensus.
Brian: I don't want the RFC++ BoF in here again. I almost got convinced it was experimental, but no. I cannot come up with success or failure criteria for Experimental.
Gorry: I don't see an Experiment. We are trying to end up with something we can standardize. We have been doing APIs in the IETF recently. We have never standarized other people's API, but this is not other people's. Architecture could maybe also be Proposed Standard. 
Tommy: I agree with Proposed Standard. I don't think Informational applies to Interface. It lies on the spectrum between Experimental and Proposed Standard. If we make it Proposed Standard, we should not have parts in it that make it Experimental, that have not been deployed and tested at scale.
Kyle: Either Experimental or Proposed Standard, based on our confidence in it and how widely it's deployed. 
Aaron: I'm fine with waiting until we get more experience and then publish a standard.
Kyle: In that case, I think proposed standard is exactly right. Also, the API is fairly abstract, so I don't see a problem with standardizing one.
Colin: I agree with Proposed Standard. Experimental we would check if it is implementable. There is a difference between "there is an implementation" and "it is implementable". There may be things we haven't implemented but we can see how to do it, and things where we are unsure if it'll work in practice. Latter case would be experimental. But preferably we'd just wait and implement it.
Zahed: (as individual) I want to emphasize experimental part. APIs go through evolution. I don't believe the interface needs to be perfect the first time. Interoperable TAPS does not make sense to me. We need to make the space for implementers to come back and give feedback. We can come up with some experimenal criteria.
Aaron: We could wait for implementation experience before publishing as PS or publish as experimental before PS.  First publishing Experimental and then Standard is kind of heavy weight.
Zahed: Would not be the first time. I want to see there is a measurable value here. That's what would make it a useful standard.
Aaron: This is such an abstract interface. A lot of the fine-tuning will happen when implementing it.
Zahed: Architecture is a good start, it will evolve and this will reflect on the interface.
Mirja: Proposed Standard does not need to be perfect. They get updated. Internet Standard has different criteria. Reason for Experimental is that we have developed a protocol, but we need to test issues at internet-scale deployment. I don't think that is the case here. If we have architecture as informational and API as Standard, there is a downref. 
Aaron: It's not normative. There's no normative language in it. But good point.
Zahed: Standard creates expectations for developers of a robust behavior. 
Mirja: What happens if it's not robust? If I implement version 1 and you version 2, it does not matter.
Zahed: You get different kinds of protocols.
Mirja: But they can talk to each other. About the downref: I think it should be a normative reference. You can have a downref. We also had architecture documents without normative language as Proposed Standard.
Pete Resnick: RFC 2026 allows Proposed Standards to be Technical Standards and Applicability statements. Proposed Standards are part of the Standards track. There is an expectation that you revise it. You can continue to make changes to it. Experimental are when you want to test something in a corner, not on the real internet. Informational is when we have not developed a protocol and we are not recommending it for something. This is Proposed Standard.
Jonathan Lennox: If there's something that could be dangerous then [it would be experimental], but you could peel that out.
Spencer: Think about the impact on the Internet. Picking between TCP and SCTP is safe, almost by definition. Please think more broadly about that. I have done many flexible things when there is a good description of what is going on in the shepherd write-up. One format of the shepherd write-up is: What track is requested and why. Just tell us the truth and we'll do the right thing.
Aaron: Let's do hums, with the assumption that we can hold publication until we get some implementation experience.

Hum for interface:
    Standards: (strong hum) (+1 from meetecho)
    Experimental: (small hum)
No hum for informational

Hum for architecture:
    Standards: (strong hum)

•  Informational: (light hum)

Hum for implementation:
   Informational: (strong hum)
   Other track: (no hum)
       
Jonathan: If here was something in implementation that describes how to implement protocols, it could be standard.
Tommy: How to map protocols could be separate documents, like "Here's how you map QUIC". Implementation should not be reference for all protocols
Brian: If there's any normative language in implementation, that specifies behaviors in the interface, that needs to be pulled back up into the interface.

Aaron: Hold document until we get implementation experience?

• Yes: (strong)
• No: (one)

Colin: We need to figure out criteria for a strong implementation.


3. An Architecture for Transport Services, draft-ietf-taps-arch-01, presenter Tommy Pauly. -20 min
        discusion point:
                - policy manager - issues
                - stack equivalence

(Slide 5)
Colin: We have to be careful because requiring reliability affects timing.
Tommy: If the application specifies timing requirements, TCP or UDP are not equivalent.

(Slide 6)
Jonathan Lennox: Would you consider DTLS equivalent to TLS?
Tommy: Chris would say No. I think we should discuss this more.
Jonathan: If I do 1.2 or 1.3 with fallback to 1.2, they are equivalent because 1.2 is allowed in both cases.
Kyle: My problem with that framing is that even the same protocol could differ in side-channels, so they are not equivalent anyway. Also here gQUIC is not equivalent to anything. Should we punt to the security area asking for what the bar is here? There might be something richer we can do here.
Tommy: Agree that we should get advice in Security area. Different things given away is the reason for Chris to not make TLS and DTLS equivalent. Please comment on the Github.


Aaron: Document mostly complete?
Tommy: Covers what we want to have. But it is going to be refined reacting to the other documents.
Gorry: There may be more architectural pieces, like policies. Might need a few more revs.
Tommy: Hopefully react to changes in the other documents.

4. An Abstract Application Layer Interface to Transport Services, draft-ietf-taps-interface-01, presenter Brian Trammell. -20 min
        discussion point:
                - document restructure 
                - micro organisation of properties

(Properties, Tommy's slides)
Tom Jones: I agree with Tommy, but I don't want a massive database of properties.
Brian: In the drafts we never actually specified that we want deterministic outcomes.

(Slide 11)
Colin: This is kind of pushing the knowledge to do framing up to the application. I'm not sure we got this right. Tommy has commented about backpressure and we have to resolve this somehow. 
Brian: You might end up with unbounded buffer attacks.
Colin: It is easier to implement the way we originally had it. This is a good starting point though.
Tommy: Philosophical question: What is it about a message that we like? 1. Message data has well-defined boundaries. 2. We can do things atomically. What we have here is not atomic. If we define Message as 1., then this does meet our needs.
Mirja: I agree with Colin. At the moment you send a message it is a block of data with a length.
Brian: Yes, this is basically a corner case where you send something too big for the protocol. Ok, there is sendfile... Well, we should talk about this.

(Slide 12)
Kyle: Option 3 is horrifying. Since when has baking a race condition into a protocol been a good idea?
Colin: There's a security issue here. Application needs to know when something is being sent. We want the default case to be very obvious to the application.
Brian: So that is in favor of option 5.
Lorenzo Colitti: Linux has two ways to use TFO. You can use whichever is more convenient.
Brian: We should dig into how Linux and Apple do this, survey them. Also the TLS stacks?
Lorenzo: You can't do TFO with OpenSSL.
Mirja: I thought the whole exercise was to not let the application choose a specific protocol. We should specify if a message is idempotent, by default it is not. 
Brian: So that is 3.5. There's a connection racing problem here as well. We're gonna do a survey and then flip a coin.

Topics for Interim: Partial Send/Receive, 0-RTT.

5. Implementing Interfaces to Transport Services, draft-ietf-taps-impl-01, presenter Anna Brunstrom. - 20 min
        discussion point:
                - updates since last version

Jonathan: Mapping - what parts of that should be normative? These parts should be moved to the end of the interfaces document.
Anna: We need to think about how to do this split. I agree that this needs to be standardized. Maybe we move some of these pieces into the API.
Brian: I see functions for this document: Show we have an idea how to handle these things, in order to justify the inclusion in the API document. Then replaced by implementation considerations. So my proposed workflow: We put stuff into this document, then stuff bubbles up in the API document, and then maybe some of it up to the architecture.
Anna: I think this process is reversed right now, in terms of what the working group is focused on.

6. Implementation experience
        6.1 New Transport networking APIs in iOS 12 beta, Tommy Pauly, Apple - 20 min        

Stuart Cheshire: Context of what kind of public beta this is: When iOS 12 ships this will be the official API. You can read the documentation.
Tommy: The documentation is not yet fully fleshed-out.

Aaron: (as chair) How well does this match with what is currently defined? How do you feel about moving closer to it as it evolves? I'm asking Apple.
Tommy: I can't speak on behalf of all of Apple. Things match up very well with the overall interaction model, our data path is quite similar. Difference is how we specify the preconnection, but this is also the area that is fairly flexible in our documents. As this becomes clearer, we will likely want to add knobs to this API. So this may be a superset of the TAPS API.
Colin: The beginning breaks down the Preconnection. Should we put this in the TAPS API?
Tommy: It is not about abstracting transport protocols. It is part of moving beyond sockets with mobility.
Kyle: Is there any hierarchy for properties? Looks like they are all at the top level.
Tommy: We will probably add hierarchy. We tried to constrain the number of parameters, they are mainly around path and not protocol selection. For protocol we do have a hierarchy, they belong in the protocol stack. These will not conflict with racing between protocols. 
Kyle: Use case would be to race between two MPLS paths. Not sure whether this is in scope for TAPS. One other nit: I like Preconnection better because it includes more than the endpoint.
Tommy: It's not a clean mapping.
Brian: Most implementations of this should be a superset of what we specify. We should specify something close to the stack agility. You said people tested and were scared of not having a stream. Is this feedback to the WG?
Tommy: This is not feedback we received from people using the API, just who were reviewing. But we don't need to focus on that.
Mirja: Are you supporting Multipath? Do you expose it?
Tommy: Yes. We expose Multipath Service Type (Handover, Interactive...)
Mirja: Given Multipath QUIC, it would be nice to have a transport-independent interface.
Tommy: Yes, but this is transport independent, does not specify MPTCP, just multipath.
Philipp Tiesel: Do you support framers?
Tommy: This is something we plan to add.

        6.2 NEAT project, Tom Jones, University of Aberdeen. - 10 min

Tommy: A lot of this is past tense. What's the future path for this implementation? Can we incorporate these ideas in a different implementation?
Tom: This is open source. Somebody would have to work on this. It's not me.

        6.3 Policy for Socket Intents, Theresa Enghardt, TU Berlin. -10 min

Kyle: Streaming connection reuse implies that the connection is in a good state and that between uses the connection is stateless in the HTTP sense.
Zahed (hat off): One LTE, you might have zero rating, so you don't necessarily want to change for certain kinds of traffic. So we need to consider network policy as part of path selection.
Tom Jones: PVD will tell you price per megabyte, etc. Can deduce appropriate path selection from that.
Zahed: Hope to have more explicit ways to input other information into the path selection.
Tommy: This seems like a layer on top of what we're specifying here in TAPS. Worried about the vagueness of some of the intents: what if the intent doesn't match reality? Maybe something higher-level can determine whether to use multi-path or not, rather than requiring the application to commit to it.
Brian: Make sure systems like intents can ride on top of the TAPS API. Be able to achieve these requirements without having to reach directly into the TAPS implementation. With a different hat on, I'd encourage you to take interface and path measurement stuff and distill it down into something that can be presented at PANRG.

7. A Survey of Transport Security Protocols, draft-ietf-taps-transport-security-02, Kyle Rose, Akamai. - 20 min
        discussion point:
                - updates since last version 
                - feedback from security area

Mirja: There are a couple of protocols that support encryption without authentication. Are these excluded?
Kyle: No. In the list of optional features there's application-level delegation of authentication. In most cases you'll want some kind of authentication. But often you want something with the application.
Mirja: How to provide authentication without encryption? Like TCP-OA? 
(comment from floor: This is out of scope)

Jonathan: Agree that security equivalence is hard. I can see an application saying that "any of gQUIC or DTLS or TLS are acceptable". Then all these can be raced.
Colin: HTTP/2 over QUIC and over TLS over TCP should be comparable. 
Kyle: There could be side-channels. I'm not sure that's the level of control we want to provide to the application.

Philipp: Does it make sense to move this security protocol equivalence to some higher layer?
Kyle: Two sides to this: There is a minimum bar, and then there is icing on a cake. The other side is that individual security protocol have their own quirks, which make them more appropriate for certain use cases. 
Brian: ISTM that Tommy's proposal for generic and specific properties could be bent in such a way to allow us to have both. Have security equivalence classes.
Kyle: Whatever framework we come up with needs to work with existing applications.
Brian: The things in the "don't care class" are the Security area's job, we can just follow them.
Tommy: Question for chairs: What do we want to do with this document? Equivalence is not THIS document. We need the formal feedback. What do you see as next steps?
Aaron: We will learn a lot in the formal review of how much work is required. If no response, would you think this document is ready?
Tommy: By the time they get back to us it would be.
Aaron: We should take it to sec dispatch and continue to work on the fine-tuning in parallel. Do you and Chris feel like you can take this to sec dispatch?
Mirja: You can just click a button to get it to review.
Anna: Is this just the survey or also the minset?
Kyle: We take a candidate set of protocols and then distill the common properties. We rely of our experience with the security area, so maybe that was implicit minset.
Anna: But in some sense it's in your tables.
Kyle: That's features somebody may want to use, but not the bar somebody would want to use.
Michael Welzl: I think having read the document, this is a minset-type document. It is similar in style. 
Kyle: How to improve it?
Michael: I commented on the list and was happy with how you addressed my comments.
Aaron: Send a note to the list as soon as the document is ready for security review.

Aaron: Interim probably in September.