Agenda bash

1. Chairs' Update (4m)

- Interim recap
- Doc status

Gorry Fairhurst:  Should we WGLC the arch doc?
Aaron Falk:  It can't be final yet, but we do want a working group review.
Brian Trammell:  Let's do a call for review, maybe even set a milestone for WG approval of the architecture.  On the agenda for Prague.
Mirja Kuhlewind:  If we call it a WGLC and don't change anything later, we don't need another one.
Aaron:  Unlikely, but sure.  Does November work?
*general agreement*
Colin Perkins:  Documents definitely, implementations maybe.
Mirja:  How about sooner?
Definite "maybe".  Not March, but before November.  July?
Tommy Pauly:  Interface in July, implementation in November.  Dedicate one meeting to each.
*general agreement*
Michael Welzl:  Changes to API document have delayed implementation draft contributions

Aaron:  Will everyone have funding that long?
Yes, those who have it now.

2. WGLC kickoff for draft-ietf-taps-transport-security - Chris (5m)

Theresa Enghardt:  We said we don't do security in minset; this draft needs to discuss how security features are exposed to applications.  How do application depedencies work? I might try contributing text.
Chris:  I understand you, but I'm not sure what to change based on that.  Talk offline.
Mirja:  What is the minimum set?
Chris:  The mandatory features.
Aaron:  So we're nearly done?
Chris:  Yes, but some reorganization left.

3. API Mappings (30m) - Tommy
* Transport API mappings for QUIC

Sean Turner:  Dragons with 0-RTT; how are we flagging this?
Tommy & Eric:  Different models, but require application opt-in before we do early data.
Subodh Iyengar:  Application protocol will vary between TCP and QUIC (HPACK vs. QPACK) -- do we provide feedback to the application?
Tommy:  Yes, applications will load different encoders.
Mirja:  H2 includes some transport semantics, so you may need a separate mapping of each version to TAPS.
Kyle Rose:  HTTP diagram "not to scale" (i.e., not to be taken literally or precisely)

Ted Hardie:  DNS over TAPS?  DNS already has transport knowledge, which complicates Tommy's models question.  Need to know the transport to choose an appropriate model.  May need API to expose this information.
Eric:  Either TAPS needs to expose that, or you need to define a common abstraction that gets mapped into different models appropriately.
Eric, Greg and Ted to discuss offline.

Philipp Tiesel:  If we had a connection pool abstraction, we don't have to compromise the two models of QUIC streams.
Mirja:  Why does one model need to open the stream?
Tommy:  This is allocating the stream, but not sending anything on the wire.
  
  * TAPS API mappings for WebRTC 

WebRTC has transport-specific low-level APIs.
Slide 4:

Colin: You're missing a step -- once you get the Preconnection results, you pass them to the peer over the data channel.  You consume the peer's list when doing the Rendezvous.
Nils Ohlmeier:  Resolve candidates produces candidate pairs.
Tommy:  Preconnection results include pairs.
Colin:  Just a set of local endpoints.  Resolve may not be the right thing; this isn't just DNS, but STUN/TURN/etc.
Cullen Jennings:  We often want to use one connection early while we're waiting for potentially-better connections to come up.

Slide 6:
Gorry:  When do you STOP_SENDING without RESET_STREAM?
Mike Bishop:  Stop reading on a unidirectional stream.
Tommy:  That's probably analogous to Close(); what TAPS is missing is closing only one direction of a bidirectional stream.
Michael Welzl:  This may depend on the mapping.

  * W3C QUIC API for WebRTC

Ted:  Comparing TAPS to WebRTC is a useful thought exercise, but W3C has run considerably ahead of QUIC's development. There will be changes when they encounter reality.  Plus I personally hate their design.
Spencer Dawkins:  We theoretically have a W3C liason.  What do we need to tell them?
Ted:  Martin Thomson is our liason.  Wendy Seltzer is their liason to us.  Martin is aware.  Harald Alvestrand is a W3C WG chair who left the room when we started talking about the W3C.

Nils:  Putting a standard over the browser APIs is strange.
Aaron:  We've learned about what each other are working on.
Cullen:  This design is coming from trying to be compatible with an existing bad design. Don't get stuck on this.
Youenn Fablet:  API needs to balance being "low and high" (details vs. abstraction)

4. draft-ietf-taps-{arch,impl,interface} topics (20m)  -- Michael
  * Connection & Message Properties

#37 - Experimental Transport Properties, which to remove or keep?

???: Direction matches QUIC and RTC
Theresa:  Direction is mentioned elsewhere in the draft, should probably move to the body.  Move cost preferences to path selection.
Brian:  Keep direction; everything else is a layer on top of TAPS
Mirja:  Let's do mappings of QUIC, WebRTC, et al. Toss anything we don't need by the end.
Gorry:  Define categories rather than specific bit rates.  Duration  is probably similar -- short, long, forever.  Size is a promise for the future.  Keep cost preferences.
Theresa:  Several of these are a layer on top of TAPS, not needed in a mapping.
Gorry:  Agreed.
Philipp:  Not sure whether we need the other layer in this draft, but perhaps in the same namespace.  Defer to after registry discussion?
Colin:  If we know bounds on send/receive rates, those might be useful input to congestion controllers.
Gorry:  More precise definition of bitrate; that's better. Let's be very precise about the semantics if we keep this.
Mirja:  Agreed. Anything in RMCat that talks about interface questions?
Colin:  Used to; bitrotten.
???:  Had this discussion previously in the framework, but not in the max/min form.  This is hard for some applications; reacting is probably the application's decision, not TAPS.
Aaron:  Let's have a specific proposal.
Mirja:  Not happy with traffic category; academia has tried to categorize forever, but describing the implications is hard. Let's see if there's anything in the implementation document that actually needs this information. Not convinced cost preferences are on the right level.
Gorry:  Categories are different ways the network carries data, not how the application describes itself.
Colin:  We have DiffServ, which I've never understood.  Need to be very clear on semantics if we do this.
Philipp via Kyle:  Going under the minimum could raise a soft error.

Michael:  "Suggest timeout to the peer" is Lars's option. Does anyone do this?  It's TCP-specific.
Lars:  Yes.
Brian:  QUIC has something similar, but not quite identical.
Lars:  Not *quite* the same thing.
Gorry:  Does anyone use it?
Lars:  Yes, Linux has it.
Mirja:  Enabled by default?
Lars:  How should I know?
Tom Jones:  In FreeBSD, and Netflix uses it.
Brian:  Lars, can you check whether it's enabled by default?
Mirja:  This is a protocol-specific feature.
Aaron:  What happens when you get a timeout?
Brian:  Transport-specific option.
Aaron:  Do we specify how to do transport-specific options?
Tommy:  Specifies that they exist, doesn't yet define any.

#208 & #218 - No objections

#243
Mike:  Editorial decision
Colin:  They need names; beyond that, don't care.
Brian:  Will make suggestions that annoy people to provoke people's actual opinions.
Philipp:  Look at registry slides; covers this.

Folks available for virtual interim before end of year? Yes.
Will discuss rest of topics then.

Didn't get to:
    
    From 4: Cached State policies

    5. Implementation updates (5m)
    6. TAPS Registry - Phillip (10m)
    7. WG use of GitHub (10m) - Chairs