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.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
