Subject: Re: [Taps] draft minutes from taps meeting in Dallas - input due by May 5

From: Aaron Falk <[email-masked]>
Date: Mon, 4 May 2015 10:36:31 -0400

Reminder: please take a look at the minutes below as they will be
submitted tomorrow.  Thanks.

--aaron

On Thu, Apr 30, 2015 at 3:47 PM, Aaron Falk <[email-masked]> wrote:
> Please provide comments and corrections by May 5th.  Many thanks to
> Wes Eddy for great notes.
>
> --aaron
>
>
> 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.