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.