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