HI, As an example of presently relied on API richness, then the following parameters of TCP/SCTP are parameters that today typically are tuned by signaling applications on a per connection/association basis or an a per signaling application basis. Here multiple signaling applications may share the same TCP/SCTP transport layer instance (SW block) but may configure their usage of the protocol (of their TCP connection/SCTP assoc differently). In terms of Taps terminology I think this corresponds to a shared " Transport Service Instance".
I may note that the parameters even typically are exposed at O&M level as configurable by the Operators, here even possibly on an association/connection basis. For TCP: RTO_MIN, RTO_MAX, MAXRT, SND BUF, RCV BUF, Delay_ack, No_delay, TCP keep alive settings, For SCTP: RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, No_delay, HBI, Association.Max.Retrans, Path.Max.Retrans, There are other parameters as well that are tuned on a per TCP connection/SCTP association basis, but this is in more special cases. For example TCP (and even SCTP) ABC slow start parameter L, TCP time wait period. The above parameters relates only to the core TCP and SCTP functions relied on by signaling applications. Speaking additional features, e.g., ECN, special SCTP features management opens up for more of course. The CC algorithm today is not tuned - default is used - in the future this should be different, but I think that there is general agreement that such should indeed be tuned at the TAPS API. BR, Karen >-----Original Message----- >From: Taps [mailto:[email protected]] On Behalf Of Aaron Falk >Sent: Monday, May 04, 2015 4:37 PM >To: [email protected] >Subject: Re: [Taps] draft minutes from taps meeting in Dallas - input due >by >May 5 > >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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
