Subject: [Taps] API richness

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 27 May 2015 08:22:15 +0200

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-masked]] On Behalf Of Aaron Falk
>Sent: Monday, May 04, 2015 4:37 PM
>To: [email-masked]
>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-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.
>
>_______________________________________________
>Taps mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Thu, 28 May 2015 21:38:32 +0200

> On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI,
> 

This strikes me as out of scope of TAPS: why discuss what (some) applications today typically tune?

> indeed be tuned at the TAPS API.

Then I think I'm in the "don't agree" camp...

Cheers,
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 29 May 2015 08:56:46 +0200

HI Michael,

Yes this api richness _may_ be out of scope of Taps.
I am writing this as information as discussed at the taps wg meeting.

If the Taps api is going to be useful I think that it is relevant to put
it in context of
the needs of applications -

Don't you think so ?

I am not saying that the taps api would need to address the present tuning
needs
described below, but I think that it is relevant to understands the
present tuning needs,
and to understand how taps fits into this.

With CC tuning, I meant control which CC algorithm to choose.

BR, Karen

>From: Michael Welzl [mailto:[email-masked]]
>Sent: Thursday, May 28, 2015 9:39 PM
>To: Karen Elisabeth Egede Nielsen
>Cc: Aaron Falk; [email-masked]
>Subject: Re: [Taps] API richness
>
>
>> 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).
>> 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,
>>
>> 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.
>
>This strikes me as out of scope of TAPS: why discuss what (some)
applications
>today typically tune?
>
>
>> 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.
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 29 May 2015 10:12:47 +0200

Hi Karen,

instead of discussing what applications currently configure, I would rather like to know why they configure it; what the goal they try to reach and what’s the problem they try to handle with that. The reason why I’m saying this, is because the current configuration possibilities are often very limited and something even on the wrong level. To figure out how to do this better, we need to understand what the application really wants.

Regarding congestion control, that’ a good example. In most implementation you can configure the algorithm used in TCP. However, usually people do not change this configuration because they don’t understand what the benefits are that a certain algorithm (with a random name) provides. Therefore actually choose the algorithm seems to be on the wrong level. The interface should rather configure what service a certain congestion control algorithm provides e.g. foreground vs. background congestion control. (Not saying that this is the right thing to do; just an example what you could do; we need to figure out what’s the right thing to do by discussing application need).

Mirja

> Am 29.05.2015 um 08:56 schrieb Karen Elisabeth Egede Nielsen <[email-masked]>:
> 
> HI Michael,
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 29 May 2015 11:25:47 +0200

HI Mirja,

>From: Mirja Kühlewind [mailto:[email-masked]]
>Sent: Friday, May 29, 2015 10:13 AM
>Cc: Michael Welzl; taps WG
>instead of discussing what applications currently configure, I would rather
>like
>to know why they configure it; what the goal they try to reach and what’s
>the
>problem they try to handle with that. The reason why I’m saying this, is
>because the current configuration possibilities are often very limited and
>something even on the wrong level. To figure out how to do this better, we
>need to understand what the application really wants.
>
[Karen ] Yes I couldn't agree more.
I will also concur that some of the present tuning is done to overcome some
deficiencies in the protocol algorithms, but generally the below reflect
needs of
the applications to have the transport layer service stay within certain
latency limits and to
bail out from using the particular transport service layer (connection) if
these limits are not withheld.

I agree than one should extrapolate to the right generic features,
to do that one should extrapolate from the existing concrete examples.

>Regarding congestion control, that’ a good example. In most implementation
>you can configure the algorithm used in TCP. However, usually people do not
>change this configuration because they don’t understand what the benefits
>are that a certain algorithm (with a random name) provides. Therefore
>actually choose the algorithm seems to be on the wrong level. The interface
>should rather configure what service a certain congestion control algorithm
>provides e.g. foreground vs. background congestion control. (Not saying
>that
>this is the right thing to do; just an example what you could do; we need
>to
>figure out what’s the right thing to do by discussing application need).
>
[Karen ] Agree.

BR, Karen
>> If the Taps api is going to be useful I think that it is relevant to
>> put it in context of the needs of applications -
>>
>> Don't you think so ?
>>
>> I am not saying that the taps api would need to address the present
>> tuning needs described below, but I think that it is relevant to
>> understands the present tuning needs, and to understand how taps fits
>> into this.
>>
>>>> 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
>>>> I may note that the parameters even typically are exposed at O&M
>>>> level as configurable by the Operators, here even possibly on an
>>>> 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.
>>>

---

From: Michael Welzl <[email-masked]>
Date: Fri, 29 May 2015 11:37:11 +0200

> On 29 May 2015, at 11:25, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Mirja,
> 
> 

Okay, it seems we're all on the same page. My heavy reaction to the email before (and sorry Karen, I had forgotten why you sent it! Indeed that was agreed upon at the last meeting) was because I'm afraid of the logical conclusion:
"this is what applications currently configure in current protocols" => "this is what a TAPS API would need to provide".

Rather, I think it would be better to focus on *why* applications currently configure the things they do, such that we can then provide something reasonable and meaningful to them.
Then again, even that is something we could spend much time on, and possibly in vain: I believe that applications that  are configuring all these things nowadays probably wouldn't be "customers" of TAPS anyway.
TAPS generally targets programmers of applications who are willing to give up some control, for the possible benefits that come with abstraction. This will always only be a subset of applications.

Cheers,
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 29 May 2015 12:22:59 +0200

Hi  Michael,

>
>Okay, it seems we're all on the same page. My heavy reaction to the email
>before (and sorry Karen, I had forgotten why you sent it! Indeed that was
>agreed upon at the last meeting) was because I'm afraid of the logical
>conclusion:
>"this is what applications currently configure in current protocols" =>
>"this is
>what a TAPS API would need to provide".

[Karen ] No problem - the clarification was important :-).
Yes I think so (one the same page).
And I did not intend to make the above corollary.

The purpose of the posting was to provide information on presently
drawn on transport service API granularity by a set of applications
(Real-time signaling applications).
I believe such information is relevant to put the abstraction of Taps into
context. Regardless of where
the line of abstraction ends up being drawn.

>
>Rather, I think it would be better to focus on *why* applications currently
>configure the things they do, such that we can then provide something
>reasonable and meaningful to them.
>Then again, even that is something we could spend much time on, and
>possibly in vain: I believe that applications that  are configuring all
>these things
>nowadays probably wouldn't be "customers" of TAPS anyway.
>TAPS generally targets programmers of applications who are willing to give
>up
>some control, for the possible benefits that come with abstraction. This
>will
>always only be a subset of applications.
>
[Karen ] Yes - the difficult job is to strike the right balance.