Minutes for TAPS at IETF-92
minutes-92-taps-1

Transport Services (TAPS) Working Group
Monday, March 23, 2015 1300 - 1500 CDT
Parisian Room

    Chair's Slides (5 min)
        Aaron Falk

    Draft Status and badgering of volunteers (15 min)
        draft-ietf-taps-transports-03
        Brian Trammell

    Applications view of transport abstractions (30 min)
        RTCWeb data channel services - Michael Tuexen
        Multisource video / TV - Marie-Jose Montpetit
        Discussion

    Two or three transport feature matrices (45 min)
        Gorry Fairhurst
        Michael Welzl
        Dave Thaler
        Discussion



The room was very full of people.

Aaron explained the agenda for the meeting.

Aaron reviewed the schedule and charter for the working group.
The initial informational document is what we're talking about today.
It probably won't be done by June, but may be "just 1 IETF behind".


----

Brian Trammell talked about the status of the document describing
transport services.

Brian described the changes made in the -03 revision, since the last
meeting.

The list of components described in -03 were reviewed.

Planned changes for the -04 revision were discussed, including some
additional protocol contributions (RTP, HTTP, websockets) that people
have volunteered to add text for, and some (MPTCP, TLS/DTLS) that
Brian is looking for people to work on.

- Mirja pointed out that Simone from Simula already volunteered 
- Kevin Fall will do TLS/DTLS

Brian thinks we could only be "1/2 an IETF behind", if people can
contribute text in the next few weeks.  The section 4 table will be
filled in in a revision -07 and in July it could be in WGLC, if the
work can get done on the mailing list.

About a dozen people indicated they're willing to do a thorough review
in this timeframe, when Aaron asked.

Brian reviewed "how to contribute", including the github URL:
https://github.com/britam/taps-transports

- Karen Nielson asked about the intended scope of "API" 

- Brian said this is a question for the room

- Mirja answered that the current APIs are described as a point of
  reference, but that the interface definition coming in the future is
 separate 

- The intention of this effort is not to obsolete existing APIs, but
  to make it easier for people building applications to use new
  mechanisms when they exist and can be used, without making them do
  probing, etc. on their own (described by Aaron).

- Karen clarified her question is about whether information about
  other APIs is something we want for this?

- Mirja said contribute it, and it may or may not be included

- Gorry said that maybe this would be useful as a separate I-D and
  that only a few paragraphs would be the goal here in the present
  document

- Michael Welzl agreed with Aaron, but said we need a
  rule/guideline/logic for what to include or not, and that some
  things shouldn't be exposed to the app (this comment "opened up a
  can of worms")

- Joe Hildebrand thinks its useful to document things the transport
  people know about but the apps people don't.

  He also has a preference to save the discussion for who is worthy
  enough to get access to certain types of information until later

- Keith Moore is concerned about notion of hiding complexity from
  applications, and wants it clear that applications need predictable
  behavior from lower layers, and that "smart" API may have complex
  behavior and not be very predictable

- Mirja suggested the network (below the transport) can be responsible
  for predictable performance, and that the features (step 2) will be
  used to decide what should be exposed

- Brian tried to explain difference between components and features,
  along with common implementations of those things, and the need to
  be careful about the distinctions in order to avoid confusion

- Michael Welzl says "in case of doubt, make the list longer now",
  removing things is not desirable.

----
Michael Tuexen talked about RTCWEB's API

It's not set in stone, but being worked on between W3C and IETF for
javascript Browser-to-browser data flow and signaling can go between
them via servers.

Michael described the protocol stack used, and noted that the API
doesn't expose all of them to the application (for instance, ICE
things happen without the application being involved with details)

Data channel concepts, abilities, and properties were explained.
Michael described the differences between what SCTP provides and what
the user has available via data channels in the RTCWEB API

- Keith Moore commented that he had a client whose flows shared fate
  and found that this API couldn't be used to do that, and that it was
  easier to do an IP tunnel underneath this API.  It's nice and
  pretty, but not that useful.  There's a lot bigger world than web
  browsers and javascript.

- Michael agreed that the scope is limited

----
Marie-Jose discussed multi-source video and (IP)TV.

She reviewed the -03 draft from her perspective of video.

Definitions and uses for multi-source video were discussed along with
issues people experience in doing this

RTP and HTTP are considered "transport" by many people (compared to
UDP and TCP).  She suggests discussing whether to add these to the
draft.

Definition of reliable transport -- suggests that a better word is
needed

- Christian Huitema from Microsoft said that TCP doesn't mean that
  you'll always succeed, but that it will try or fail

- Marie-Jose does not disagree with this

- Dave Crocker - largest point is that when different communities use
  the same word differently it creates problem.  suggests "usability"
  as a term

- Someone from CableLabs asked how this is different than QoS

- Marie-Jose said that QoS and QoE are things she will not get into

- David Black strongly agrees with Quality of Experience; if the video
  won't render, the user is not happy.  codec + network determine QoE.

- Marie: it's called "engineering”.

- David: that's this organization's middle name.

- Aaron said that "timely delivery" is fundamental and maybe not
  QoS/QoE 

- Marie said that delivering in time as well as quality are different
  layers 

- Christian Huitema from Microsoft said that having the application
  express what it wants (FEC or retransmission) would be useful

- Dave Crocker contemplating terms and likes QoE

- Toerless Eckert talked about packets in a video stream having
  different priorities (you don't want to lose I-frames) ... similar
  things in markets, IoT, etc.

- Marie suggested supporting exposing and querying the capabilities of
  the lower layers e.g. IEEE 1905.

- Matt Mathis is in complete agreement.  History littered with stories
  about apps reinventing "broken almost TCP or something".  both a
  simple and a rich way for applications to use the API are necessary

- Keith Moore totally agrees.  applications could get more predictable
  behavior by forcing them to make decisions.

  Library developers writing code for others to reuse are a small
  number of people, and most sane developers will reuse libraries
  rather than redo things from scratch

- Jana Iyengar said to think about exposing info to functions rather
  than to protocols, because the functions may exist in multiple
  layers.  He does not think QoE is a good term.

- Mirja and Brian T both wanted to make the point that some things can
  be exposed (like TCP working but UDP not, over a given path) to save
  duplicated effort


----
Gorry Fairhurst talked about set of transport service features

He showed the table from the draft of protocol components that offer API
features.

- Jana asked if we were going to do the trimming here.

- Gorry suggested 2 lists:
  - things done in transport
  - things offered to upper layer

- Jana suggests a filter on top for things that are actually deployed
  (i.e.  DCCP, UDP-Lite, etc don't count)

- Mirja suggests we discuss ECN because the job wasn't done well in
  getting it running, and that checks aren't properly done in the
  transport about whether it's working so that's why it can be exposed

- Gorry said that it leads to mechanics above

- Mirja said that's why they should be in the transport already

- Christian (Microsoft) said that some functions are missing.
  congestion control and security points.

- Gorry said that he's looking for volunteers on this.

- Magnus reacting to ECN, he worked on ECN for RTP and said it does
  need to be tied into the higher layers, for instance the codec or
  something above RTP is what needs to deal with it.

- Magnus also pointed out that some multicast/RMT protocols are used
  in unicast world.

- Brian Adamson will offer text on this.

- Colin Perkins said this is a restrictive/traditional view of
  transports and that RTP should go in here.  Colin will help Varun
  write something here.

- Jana Iyengar said this is what he meant by functions versus
  protocols earlier

- Keith Moore asked if there was time to discuss if this was all a bad
  idea.  He needs to discuss this on the mailing list.

- Mark Nottingham asked how to account for differences in quality or
  properties of different implementations.  HTTP2 was remapped onto
  the same transport protocol and has vastly different properties.

- Gorry said it's just documenting what's out there, in order to have
  the discussion later.

- Keith said that adding more layers of abstraction will not make
  things better.  He spent 5 years trying to build an API similar, and
  path selection was one feature that would have needed 10 more
  bullets to explain why the application needs to know what its IP
  addresses are.

- Joe Hildebrand with IAB hat on is interested in seeing work progress
  by doing at least the first and second step, and maybe Experimental
  third step, but sees architectural value in at least first 2 steps.

- Chris Newman sees visibility as missing in the list because the
  logging and auditing of all the knobs of the lower layers is
  important and applications should be able to get that.

- Gorry asked if this influences selection of transport

- Chris says absolutely, and totally disagrees with Mirja's statement
  about just expressing the needs and letting the transport be
  selected; he would be unable to use that kind of system, he wants to
  know what was selected and all the details.

- Brian Trammell - we need to write down visibility of what's going on
  inside the transport as a requirement and move on (room seems to
  agree)

- Matt Mathis - browser people have abstracted everything away about
  the network, and idempotence is important (and not understood by
  web) but should be on the list somehow

- Phil Halam-Baker done security, apps, most parts of stack, and says
  to never ever tell someone they can't do something.  there are two
  ways to look at the problem, one is the sockets api, or just dns and
  service names and that's all.  More abstraction *can* help, but not
  just a little, way more abstraction

- Colin Perkins said that some applications need to know "how well it
  worked perfectly".  was surprised that some primitive for building
  nat traversal or discovering middleboxes wasn't on the list.

- Brian suggests spud BoF as place to discuss this.

- Colin said there's also talking to middleboxes for things like
  partial encryption, decoupled congestion control loops, etc.

- Toerless asked about naming.

- Gorry said it varies between transports.

- Toerless said waterfall process to do APIs at the end is not really
  working, and there should be compromise position that we'll do APIs
  at the end and track inputs to it (e.g. via wiki) in the meantime

- Dave Thaler said there's a lot of angst around the notion of APIs,
  and there are vastly divergent views.  it's useful to know what RMT
  ran into when they did this decomposition of building blocks for
  multicast services

- Jana: +1 to what Dave just said

- Mirja: working group is not chartered to hide information, but to
  expose more; she asks "why?" when people ask for information so that
  she can make sure they're getting the right information

- Chis Newman suggests secure by default as a philosophy.