Subject: [Taps] First draft of an article for the IETF journal

From: Michael Welzl <[email-masked]>
Date: Tue, 20 May 2014 09:52:42 +0200

Dear all,

I was invited to write an article about the TAPS BOF for the IETF journal, with deadline end of May ("exact due date TBD"). This is the information they gave me:

***
For BoFs, most articles end up being an overview of the BoF, its goals, and any next steps and/or ongoing work. Pictures and figures are welcome, too, as separate high-resolution files.

Articles can be anywhere from 500-1500 words, but we are pretty flexible if you have more or less to say.

We publish articles online to http://www.internetsociety.org/publications/ietf-journal and our Twitter account ( http://twitter.com/ietfjournal) as they are finalized, and then package everything into a print version just in time for the next IETF.
***

I produced the text below, with two figures attached to this email. Please let me have any comments / suggestions by the end of this week latest, thanks!

Cheers,
Michael

********************************************************

TAPS BOF

SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism offer a large number of services to applications in addition to the long-standing two services provided by TCP and UDP. For an application programmer, using protocols other than TCP or UDP is hard: not all protocols are available everywhere, hence a fall-back solution must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and chances of benefiting from other transport protocols are lost. The intention of the Transport Services (TAPS) initiative is to identify the services provided by IETF transport protocols and congestion control mechanisms as well as network requirements of applications and the APIs they use to communicate. By finding a mapping between these lists, a potential later WG could define services that a transport API should offer. Then, it would specify how these transport services can be implemented using native IETF transports and encapsulated transports, including the definition of mechanisms to validate that a transport (or transports) can be supported on a path.

The TAPS initiative began in August 2013 with a mailing list and an accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, where it was already clarified that TAPS should be careful to provide what application programmers really need instead of being too focused on the Berkeley Sockets API. Accordingly, several Internet-drafts were written, including use cases and an overview of how higher level APIs could better be supported by enhanced IETF transport services. By breaking the dependency of applications on specific protocols, TAPS has the potential to make the currently rigid transport layer more flexible; this is schematically shown in Figure 1. In December 2013, a presentation was given at the IAB Workshop on Internet Technology Adoption and Transition in Cambridge, UK, explaining how the evolutionary benefit of TAPS is connected to its best-effort nature. These activities culminated in a Birds-of-a-Feather (BoF) meeting at IETF-89. This BoF was designated "non-WG-forming" to allow the IETF community to discuss the various angles of this large problem space without having to spend time on charter word-smithing. Discussion was indeed lively at this two-hour long session, with 129 attendees and a debate in which more than 6650 words were spoken at the microphone.

There were four presentations at the TAPS BoF: Jon Crowcroft outlined the potential of this activity, calling it "socket science" and putting it in relation to security. Then, Martin Sustrik presented how middleware such as his own ZeroMQ could benefit from transports other than TCP; notably, the strict reliability of TCP is a poor match for pub/sub communication. As shown in Figure 2, updating middleware offers an easy deployment path, where applications could exploit some of the benefits of TAPS without having to be changed (except for re-compiling with a new version of the middleware). Gorry Fairhurst presented a possible implementation of TAPS, and Margaret Wasserman presented the API of the Multiple Interfaces (MIF) Working Group. This API is clearly related, and it seems obvious that a TAPS API should be somehow connected to the MIF API.

All presentations were accompanied by active debate. For example, not everyone agreed with the particular way of providing transport services that was presented. The flexibility shown in Figure 1 comes at a cost -- application programmers may need a very predictable behavior, where a certain way of using an API always leads to the exact same protocol choice underneath. This point was made by Stuart Cheshire from Apple, who suggested to make such decisions at development time, not at runtime; Marie-José Montpetit from MIT stressed the importance of testing. Changing the transport protocol must not break an application. Ran Atkinson and Dave Thaler suggested to support name-based instead of IP-address-based transports, at least as an option. Several participants stated that TAPS should not be focusing on an API -- for example, Pete Resnick said that TAPS should be thought about in terms of a layer, and we should leave it to OSes that interface with applications to do the work to build the API and actually produce the layer that we want with all the information that we want and whatever APIs are needed.

There is an ongoing conversation between the TSV ADs who sponsored the TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. The group’s mailing list, [email-masked], currently has 120 subscribers, and can be joined at https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is at https://sites.google.com/site/transportprotocolservices.

Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) were part-funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the author(s).

Figure 1 caption text: Without TAPS (left), the application is tied to protocol X. With TAPS (right), the application could benefit from protocol Y that is supported by ISP B.

Figure 2 caption text: Before (left) and after (right) applying TAPS below a non-TAPS-enabled application. Nothing changes in the application and the middleware API that it uses.

---

From: Aaron Falk <[email-masked]>
Date: Tue, 20 May 2014 10:01:26 -0400

Hi Michael-

This is a nice writeup and, while I wasn't at the BoF, it seems consistent
with the minutes, drafts and presentations I've seen.  I have a few
comments:

I think it would be more accessible to non-Transport folks if the first
paragraph included a couple of descriptions of the capabilities of
protocols other than TCP or UDP to give some motivation of why anyone would
want to see TAPS succeed.  The list of acronyms at the beginning of the
article may be a turn-off to anyone who doesn't recognize them.  I realize
you have space constraints but consider most folks reading this will be
non-experts - think managers.  (The experts will read the minutes.)

Second, the paragraph on debate is one of the most important since it
highlights some of the open issues that may affect the success of the work.
 I'd suggest restructuring it to minimize the names of the individuals and
expand on the core concerns: predictability, safety, binding mechanisms,
layer vs. API.  Maybe a bulleted list?

Third, and this is sort of beyond the article although you did invoke the
topic, I've been thinking about deployment for TAPS.  It seems important to
have a believable deployment story since it has been deployment issues that
have hampered use off some of the transport protocols that TAPS intends to
make more available.  Seems to me like the deployment challenge may
actually be harder if you are creating a new layer / api since you need
both ends of the app to support it as well as both stacks.  Has there been
any discussion of this?  Maybe I'm missing something obvious. If so, it's
worth stating as part of the concept and if not it's worth listing as an
open issue.

Hope this is helpful,

--aaron

On Tue, May 20, 2014 at 3:52 AM, Michael Welzl <[email-masked]> wrote:

> Dear all,
>
> I was invited to write an article about the TAPS BOF for the IETF journal,
> with deadline end of May ("exact due date TBD"). This is the information
> they gave me:
>
> ***
> For BoFs, most articles end up being an overview of the BoF, its goals,
> and any next steps and/or ongoing work. Pictures and figures are welcome,
> too, as separate high-resolution files.
>
> We publish articles online to
> http://www.internetsociety.org/publications/ietf-journal and our Twitter
> account ( http://twitter.com/ietfjournal) as they are finalized, and then
> package everything into a print version just in time for the next IETF.
> ***
>
>
> I produced the text below, with two figures attached to this email. Please
> let me have any comments / suggestions by the end of this week latest,
> thanks!
>
>
> Cheers,
> Michael
>
> SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism
> offer a large number of services to applications in addition to the
> long-standing two services provided by TCP and UDP. For an application
> programmer, using protocols other than TCP or UDP is hard: not all
> protocols are available everywhere, hence a fall-back solution must be
> implemented. Some protocols provide the same services in different ways.
> Layering decisions must be made (e.g. should a protocol be used natively or
> over UDP?). Because of these complications, programmers often resort to
> either using TCP or implementing their own customized solution over UDP,
> and chances of benefiting from other transport protocols are lost. The
> intention of the Transport Services (TAPS) initiative is to identify the
> services provided by IETF transport protocols and congestion control
> mechanisms as well as network requirements of applications and the APIs
> they use to communicate. By finding a mapping between these lists, a
> potential later WG could define services that a transport API should offer.
> Then, it would specify how these transport services can be implemented
> using native IETF transports and encapsulated transports, including the
> definition of mechanisms to validate that a transport (or transports) can
> be supported on a path.
>
> The TAPS initiative began in August 2013 with a mailing list and an
> accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, where
> it was already clarified that TAPS should be careful to provide what
> application programmers really need instead of being too focused on the
> Berkeley Sockets API. Accordingly, several Internet-drafts were written,
> including use cases and an overview of how higher level APIs could better
> be supported by enhanced IETF transport services. By breaking the
> dependency of applications on specific protocols, TAPS has the potential to
> make the currently rigid transport layer more flexible; this is
> schematically shown in Figure 1. In December 2013, a presentation was given
> at the IAB Workshop on Internet Technology Adoption and Transition in
> Cambridge, UK, explaining how the evolutionary benefit of TAPS is connected
> to its best-effort nature. These activities culminated in a
> Birds-of-a-Feather (BoF) meeting at IETF-89. This BoF was designated
> "non-WG-forming" to allow the IETF community to discuss the various angles
> of this large problem space without having to spend time on charter
> word-smithing. Discussion was indeed lively at this two-hour long session,
> with 129 attendees and a debate in which more than 6650 words were spoken
> at the microphone.
>
> There were four presentations at the TAPS BoF: Jon Crowcroft outlined the
> potential of this activity, calling it "socket science" and putting it in
> relation to security. Then, Martin Sustrik presented how middleware such as
> his own ZeroMQ could benefit from transports other than TCP; notably, the
> strict reliability of TCP is a poor match for pub/sub communication. As
> shown in Figure 2, updating middleware offers an easy deployment path,
> where applications could exploit some of the benefits of TAPS without
> having to be changed (except for re-compiling with a new version of the
> middleware). Gorry Fairhurst presented a possible implementation of TAPS,
> and Margaret Wasserman presented the API of the Multiple Interfaces (MIF)
> Working Group. This API is clearly related, and it seems obvious that a
> TAPS API should be somehow connected to the MIF API.
>
> All presentations were accompanied by active debate. For example, not
> everyone agreed with the particular way of providing transport services
> that was presented. The flexibility shown in Figure 1 comes at a cost --
> application programmers may need a very predictable behavior, where a
> certain way of using an API always leads to the exact same protocol choice
> underneath. This point was made by Stuart Cheshire from Apple, who
> suggested to make such decisions at development time, not at runtime;
> Marie-José Montpetit from MIT stressed the importance of testing. Changing
> the transport protocol must not break an application. Ran Atkinson and Dave
> Thaler suggested to support name-based instead of IP-address-based
> transports, at least as an option. Several participants stated that TAPS
> should not be focusing on an API -- for example, Pete Resnick said that
> TAPS should be thought about in terms of a layer, and we should leave it to
> OSes that interface with applications to do the work to build the API and
> actually produce the layer that we want with all the information that we
> want and whatever APIs are needed.
>
> There is an ongoing conversation between the TSV ADs who sponsored the
> TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps.
> The group’s mailing list, [email-masked], currently has 120 subscribers,
> and can be joined at https://www.ietf.org/mailman/listinfo/taps. The
> accompanying webpage is at
> https://sites.google.com/site/transportprotocolservices.
>
> Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) were
> part-funded by the European Community under its Seventh Framework Programme
> through the Reducing Internet Transport Latency (RITE) project
> (ICT-317700). The views expressed are solely those of the author(s).
>
>
>
> Figure 1 caption text: Without TAPS (left), the application is tied to
> protocol X. With TAPS (right), the application could benefit from protocol
> Y that is supported by ISP B.
>
> Figure 2 caption text: Before (left) and after (right) applying TAPS below
> a non-TAPS-enabled application. Nothing changes in the application and the
> middleware API that it uses.
>
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>
>

---

From: Martin Sustrik <[email-masked]>
Date: Tue, 20 May 2014 16:11:23 +0200

Hi Michael,

I am sorry for not writing down the extract of my talk myself. I've
been extremely busy in past few weeks.

> Then, Martin Sustrik presented how middleware such as his own
> ZeroMQ could benefit from transports Maother than TCP; notably, the
> strict reliability of TCP is a poor match for pub/sub
> communication.

That very much wraps it. I would add one more sentence though:
"Moreover, middleware layer often has enough information about what
the user is trying to achieve to ask for specific transport services
itself and not require the user to do so."

Martin

---

From: Toby Moncaster <[email-masked]>
Date: Tue, 20 May 2014 15:16:08 +0100

Michael,

I like Martin’s addition because it closes off one of the arguments people use against this work. I think I would word it slightly differently to say “Such middleware layers are increasingly common and often have enough information about what the user is trying to achieve to be able to make informed transport choices on their behalf."

There are a few minor changes I might make to the text, but overall it reads well, summarises what happened at the BoF and gives a good oversight of the problem space.

Toby

On 20 May 2014, at 15:11, Martin Sustrik <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Michael,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTe2KLAAoJENTpVjxCNN9YvacH/R8P3qu1Xhwmqv9cdA1j4r49
> qnhFfqQxk4lw0ZXH8+v5XOgkNXyGpOV1i2C1wsPuRpf6xG75T7ZFyj5rbrq0oHcs
> 5qbOTndP5gL6rIcFb5WVAHYkzszIiLKOOO5bghCO2LshDQ6d4jYEtjje0BWKgIyA
> 0Bk3+ReSlrNPSlrRKTm4zXM8OyJfGqhzO4zTqOyKRr3xOHhrP+Fhtee2kXcyiull
> n8p1Hns3wjmU8BsibSF0JVjm6RdjRL43S+xHrxQ7G3kpEP/+3MM/sA31sYNiLu58
> +u+Mn+X+Ec8qfIztNrWvAtlL7Tm1YNZ7VJSj4J+pHuqbujqArAW9rtbG0rMyaZI=
> =ELHc
> -----END PGP SIGNATURE-----
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 21 May 2014 10:29:22 +0200

Hi,

> I like Martin’s addition because it closes off one of the arguments people use against this work. I think I would word it slightly differently to say “Such middleware layers are increasingly common…

Thanks, incorporated (I agree, I like his statement too, but your wording is nicer).

> There are a few minor changes I might make to the text, but overall it reads well, summarises what happened at the BoF and gives a good oversight of the problem space.

Please, by all means, go ahead!

(but note I'll send an update that has all the suggestions to the list in a few mins)

---

From: Michael Welzl <[email-masked]>
Date: Wed, 21 May 2014 11:11:08 +0200

Hi,

On 20. mai 2014, at 16:01, Aaron Falk wrote:

> Hi Michael-
> 
> This is a nice writeup and, while I wasn't at the BoF, it seems consistent with the minutes, drafts and presentations I've seen.  I have a few comments:
> 
> I think it would be more accessible to non-Transport folks if the first paragraph included a couple of descriptions of the capabilities of protocols other than TCP or UDP to give some motivation of why anyone would want to see TAPS succeed.  The list of acronyms at the beginning of the article may be a turn-off to anyone who doesn't recognize them.  I realize you have space constraints but consider most folks reading this will be non-experts - think managers.  (The experts will read the minutes.)
> 
> Second, the paragraph on debate is one of the most important since it highlights some of the open issues that may affect the success of the work.  I'd suggest restructuring it to minimize the names of the individuals and expand on the core concerns: predictability, safety, binding mechanisms, layer vs. API.  Maybe a bulleted list?

Thanks a lot for these suggestions! All incorporated.

> Third, and this is sort of beyond the article although you did invoke the topic, I've been thinking about deployment for TAPS.  It seems important to have a believable deployment story since it has been deployment issues that have hampered use off some of the transport protocols that TAPS intends to make more available.  Seems to me like the deployment challenge may actually be harder if you are creating a new layer / api since you need both ends of the app to support it as well as both stacks.  Has there been any discussion of this?  Maybe I'm missing something obvious. If so, it's worth stating as part of the concept and if not it's worth listing as an open issue.

My opinion: at first, we should focus on things that can be installed one-sided, on the sender side only.
Yes it's limited, but a number of things are possible there. E.g., pluggable congestion controls in TCP have always worked without involving the receiver - but right now, pluggable congestion control isn't an IETF matter. Happy Eyeballs can be done without coordinating with a receiver, at least for the case that we're using well-known ports and the receiver listens on more than one protocol.

But yes, quite quickly one runs into limitations there; anyway, for divide-and-conquer  :-)   reasons, I think we want to go with a sender-side-only-installation assumption for now. Though, I'm not sure if we have had enough discussions on this and if absolutely everyone is on the same page (though, indirectly perhaps, as our draft charter states that signaling is out of scope, and signaling would be needed to align both ends).

Cheers,
Michael