Subject: [Taps] IETF journal article update

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

Hi,

Here's an update of the text, incorporating the many comments I received. Thanks a lot to all of you who made suggestions! Further comments are very welcome, of course.

Cheers,
Michael

TAPS BOF

The protocols 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 example, SCTP provides reliable and potentially faster-than-TCP delivery of data chunks to applications that may be able to accept such chunks out of order. DCCP provides various forms of congestion control for applications that need it, but would rather have their packets dropped than retransmitted, as the latter can lead to delay. LEDBAT provides a scavenger-like background transfer mode, where LEDBAT traffic does not get in the way of other transfers that use TCP, for instance. Useful as these services may be, using them is hard for an application programmer: 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 (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), 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. 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. 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.

predictability, safety, binding mechanisms, layer vs. 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 major concerns that were raised are:
- Predictability: 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. It was  suggested that such decisions should be made at development time, not at runtime.
- Safety: the importance of testing was stressed; changing the transport protocol must not break an application.
- Binding mechanisms: going even beyond what TAPS proposes, it was suggested to support name-based instead of IP-address-based transports, at least as an option.
- Layer vs. API: several participants stated that TAPS should not be focusing on an API -- it was 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.

References:
[1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
[2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol"

---

From: Brian Adamson <[email-masked]>
Date: Wed, 21 May 2014 06:57:57 -0400

Hi Michael,

Are there plans to also include multicast transport protocols under the TAPS umbrella?  For example, I recently ported our NORM (RFC 5740) implementation into the ZeroMQ libzmq library to take advantage of API it provides.  However, there's quite a bit of added NORM features that could be tapped (no pun intended) with additional API primitives beyond what ZeroMQ currently provides to meet different multicast application needs.  It may be useful to mention if TAPS may address multicast transport capabilities as well.

best regards,

Brian

On May 21, 2014, at 5:12 AM, Michael Welzl <[email-masked]> wrote:

> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

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

Hi,

Are there plans: I think it hasn't really been brought up yet.
My personal opinion: yes, we should include multicast.

Other opinions?

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 May 2014 12:35:53 +0100

My thoughts at this moment:

I'd be keen to see multicast supported in the architecture - but I am 
less sure we should initially open work items on multicast APIs and 
mechanisms, since this may be a wider set of behaviours and use-styles. 
I'd prefer to focus initial specification work on a few things for which 
we expect the most common use.

gorry

On 21/05/2014 12:25, Michael Welzl wrote:
>>> The protocols 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 example, SCTP provides reliable and potentially faster-than-TCP delivery of data chunks to applications that may be able to accept such chunks out of order. DCCP provides various forms of congestion control for applications that need it, but would rather have their packets dropped than retransmitted, as the latter can lead to delay. LEDBAT provides a scavenger-like background transfer mode, where LEDBAT traffic does not get in the way of other transfers that use TCP, for instance. Useful as these services may be, using them is hard for an application programmer: 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 (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), 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. 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. 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 AP
I should be somehow connected to the MIF API.

---

From: Brian Adamson <[email-masked]>
Date: Wed, 21 May 2014 11:05:56 -0400

I understand the need to keep the initial focus on higher priority parts that may enjoy more common use.  In some cases, depending how TAPS manifests itself, could there be application-layer “communication patterns” that are invoked and the underlying system identifies what mix of multicast (if applicable) and unicast makes sense given system capabilities, the specified application needs, etc?  For example, with my recent experience with the ZeroMQ PUB/SUB, their APIs do currently require the application to identify whether the PUB/SUB is done via unicast or multicast, but I could envision middleware that might make its own determination based on the underlying network topology and capabilities.  I.e, there would not necessarily be specific differentiation of unicast versus multicast APIs, but more the general means for the application to express its data transfer needs …

cheers,

Brian

On May 21, 2014, at 7:35 AM, Gorry Fairhurst <[email-masked]> wrote:

> I'd be keen to see multicast supported in the architecture - but I am less sure we should initially open work items on multicast APIs and mechanisms, since this may be a wider set of behaviours and use-styles. I'd prefer to focus initial specification work on a few things for which we expect the most common use.
> 
> gorry
> 
> 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 (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), 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.
>>>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 May 2014 16:12:36 +0100

I agree with all this...

Gorry

---

From: Martin Sustrik <[email-masked]>
Date: Wed, 21 May 2014 17:22:52 +0200

Hi Brian,

> I understand the need to keep the initial focus on higher priority 
> parts that may enjoy more common use.  In some cases, depending
> how TAPS manifests itself, could there be application-layer 
> “communication patterns” that are invoked and the underlying
> system identifies what mix of multicast (if applicable) and unicast
> makes sense given system capabilities, the specified application
> needs, etc?

I believe this ("communication patterns") is a really hard problem as
it encompasses the entire field of distributed computing. Too much of
responsibility for a humble working group like this.

> For example, with my recent experience with the ZeroMQ PUB/SUB, 
> their APIs do currently require the application to identify
> whether the PUB/SUB is done via unicast or multicast,

The difference is only when specifying an endpoint address, right?
Other than that, PUB/SUB works conceptually the same for both
multicast and unicast.

> but I could envision middleware that might make its own
> determination based on the underlying network topology and
> capabilities.  I.e, there would not necessarily be specific
> differentiation of unicast versus multicast APIs, but more the
> general means for the application to express its data transfer
> needs …

I've actually touched this topic in my TAPS presentation. The idea was
that there is a clean separation of mechanism ("I want to do PUB/SUB")
and policy ("I want this communication to happen on top of NORM").

The former is something that programmer specifies as it is integral
part of the business logic.

The latter is a just a policy that can be set by administrator,
figured out automatically by a heuristic etc.

Martin

Martin

---

From: Brian Adamson <[email-masked]>
Date: Wed, 21 May 2014 18:17:33 -0400

Yes - definitely some need to put some scope limit on the thoughts here.  I wasn't able to make the London BoF as I hoped and still need to review the presentations from that so I apologize if I'm speaking out of turn.  I just meant to ask about the lack of mention of multicast in journal article ...

I was using the ZeroMQ PUB/SUB pattern as an example.  As you point out, the only difference for multicast/unicast was changing the endpoint address.  It's quite nice that it's that simple and the nice API that abstracts a useful base set of communication pattern primitives that can be leveraged for multiple purposes is a big part of what motivated me to dabble with it.  There are some variations of those "patterns" or different ways the patterns might be instantiated (e.g. using some of the different protocols or mixes of those that Michael identified in his writeup) that could be explored and may be relevant to TAPS goals if the an appropriate scope is identified.  I don't think there is an infinite number of these and there might be some taxonomy supportable by TAPS?  Some examples of what I mean that come to mind include supporting live media pub/sub, asymmetric communication models (e.g. pub/sub with multicast pub and unicast subscription handling) and that's just for the pub/sub pattern.  Even if TAPS doesn't encompass all of this, at least thinking about these sorts of use cases, as I'm sure _you_ have ;-), can help identify what TAPS does do.  Again, I apologize if this is redundant to discussion already held.  I need to do my homework and catch up on what was discussed in London.

cheers,

Brian

On May 21, 2014, at 11:22 AM, Martin Sustrik <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Brian,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTfMTMAAoJENTpVjxCNN9YmRUH/iXRbqPPycyD+ZAXqwgXr3bT
> /hh/Ovu8scQ2bpA/Ds2pw+Xuncs1u3DNP8eX+5tasBRGhhuhXK/Yq7LBMWU9FPaa
> 5zzq/eiuzrS1DendtbTWT9Xbo36oINNXHs2zGrSYtbNJTwuU80nItaUwnsEl08q2
> 8GOnQNVdeglkY9Bon6aAGbqaZrxgBQsngNfbczWOvkSO662G/4Nzpr7xK3zyZSba
> Agpi2slCERImo2rmfiudFYxKiaEwuKFG2Ud3YRsOo3G0ju8p/bl1cwLVCRIaq5ev
> 6/bfc1XJMh+o5FrLXp+4z5mthygvX++z/4RyfDYNxmhxRnXQhDpnE8xtj/oHtus=
> =1M+M
> -----END PGP SIGNATURE-----

---

From: Michael Welzl <[email-masked]>
Date: Thu, 22 May 2014 11:11:34 +0200

> I was using the ZeroMQ PUB/SUB pattern as an example.  As you point out, the only difference for multicast/unicast was changing the endpoint address.  It's quite nice that it's that simple and the…

Correct me if I'm wrong: you're arguing for having more abstract, pattern-oriented text rather than just the list of APIs in draft-hurtig-tsvwg-transport-apis-00 ?

What about changing the title of this document to "Transport support for APIs and Communication Patterns" and adding a section that identifies how certain communication patterns, not just specific APIs, could generally be better supported by different transports? Would that be what you're thinking of?

(careful, this is a trap: if your answer is yes, then obviously, my next suggestion is for you to become a co-author of this draft and offer text  :-)   )

Cheers,
Michael

---

From: Martin Sustrik <[email-masked]>
Date: Thu, 22 May 2014 21:34:55 +0200

On 22/05/14 00:17, Brian Adamson wrote:
> Yes - definitely some need to put some scope limit on the thoughts 
> here.  I wasn't able to make the London BoF as I hoped and still
> need to review the presentations from that so I apologize if I'm
> speaking out of turn.  I just meant to ask about the lack of
> mention of multicast in journal article ...
> 
> I was using the ZeroMQ PUB/SUB pattern as an example.  As you
> point out, the only difference for multicast/unicast was changing
> the endpoint address.  It's quite nice that it's that simple and
> the nice API that abstracts a useful base set of communication
> pattern primitives that can be leveraged for multiple purposes is a
> big part of what motivated me to dabble with it.  There are some
> variations of those "patterns" or different ways the patterns might
> be instantiated (e.g. using some of the different protocols or
> mixes of those that Michael identified in his writeup) that could
> be explored and may be relevant to TAPS goals if the an appropriate
> scope is identified.  I don't think there is an infinite number of
> these and there might be some taxonomy supportable by TAPS?  Some
> examples of what I mean that come to mind include supporting live
> media pub/sub, asymmetric communication models (e.g. pub/sub with
> multicast pub and unicast subscription handling) and that's just
> for the pub/sub pattern.  Even if TAPS doesn't encompass all of
> this, at least thinking about these sorts of use cases, as I'm sure
> _you_ have ;-), can help identify what TAPS does do.

Yes, I've been thinking about the patterns for nearly a decade now.
And yes, I believe they should be formalised. I've even tried to write
some experimental RFCs. Here's the one for REQ/REP pattern, for example:

https://raw.githubusercontent.com/nanomsg/nanomsg/master/rfc/sp-request-reply-01.txt

All that being said, I still believe that including such work into
TAPS would be a serious case of mission creep.

Still, if people are interested in discussing communication patters, I
am happy to do so. I am not sure what the appropriate forum would be
for that though. AFAIK IETF doesn't even have an area that would fit
this "interaction protocols among many nodes" stuff.

Martin

---

From: Aaron Falk <[email-masked]>
Date: Mon, 26 May 2014 22:51:05 -0400

Michael-

Much improved.  One nit: the para about open issues starts with a sentence
fragment.

Thanks!

--aaron

On Wed, May 21, 2014 at 5:12 AM, Michael Welzl <[email-masked]> wrote:

> Hi,
>
> Here's an update of the text, incorporating the many comments I received.
> Thanks a lot to all of you who made suggestions! Further comments are very
> welcome, of course.
>
> Cheers,
> Michael
>
>
> TAPS BOF
>
> The protocols 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
> example, SCTP provides reliable and potentially faster-than-TCP delivery of
> data chunks to applications that may be able to accept such chunks out of
> order. DCCP provides various forms of congestion control for applications
> that need it, but would rather have their packets dropped than
> retransmitted, as the latter can lead to delay. LEDBAT provides a
> scavenger-like background transfer mode, where LEDBAT traffic does not get
> in the way of other transfers that use TCP, for instance. Useful as these
> services may be, using them is hard for an application programmer: 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
> (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), 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. 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. 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 major concerns that were raised are:
> - Predictability: 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. It was  suggested that such decisions should be made at
> development time, not at runtime.
> - Binding mechanisms: going even beyond what TAPS proposes, it was
> suggested to support name-based instead of IP-address-based transports, at
> least as an option.
> - Layer vs. API: several participants stated that TAPS should not be
> focusing on an API -- it was 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.
>
>
> References:

---

From: Aaron Falk <[email-masked]>
Date: Mon, 26 May 2014 22:54:29 -0400

On Thu, May 22, 2014 at 5:11 AM, Michael Welzl <[email-masked]> wrote:

>
> What about changing the title of this document to "Transport support for
> APIs and Communication Patterns" and adding a section that identifies how
> certain communication patterns, not just specific APIs, could generally be
> better supported by different transports? Would that be what you're
> thinking of?
>
> (careful, this is a trap: if your answer is yes, then obviously, my next
> suggestion is for you to become a co-author of this draft and offer text
>  :-)   )
>
>
Yikes, this seems like pretty significant scope creep and an attractive
topic for discussion and debate, a bad combination for working group
chartering.  :-/  Nevertheless, I agree it is interesting and relevant.
 Maybe it would be worthwhile to have a draft proposing how communication
patterns could be included in an API framework to see if there's rapid
consensus?  I would love to be pleasantly surprised...

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 May 2014 08:44:36 +0200

Hi,

Thanks a lot! I sent it on yesterday, but luckily discovered exactly that one mistake too as I did so.

Thanks again for your inputs!!
Michael

On 27. mai 2014, at 04:51, Aaron Falk wrote:

> Michael-
> 
> Much improved.  One nit: the para about open issues starts with a sentence fragment.
> 
> Thanks!
> 
> --aaron
> 
>

---

From: [email-masked]
Date: Tue, 27 May 2014 07:49:33 +0100

Yes, I agree - this looks good to me,

Gorry

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 27 May 2014 08:32:56 +0100

totally agree - I think generalized pattern approach is really nice, and we
tried using it in the "building blocks" structure that was used in the RMT
group - i think quite successfully

however, patterns (and RMT consierations too) are over-reach for TAPS, in
my opinion....life's too short to get something done that new, big, and
complex (and contentious in some quarters)

On Thu, May 22, 2014 at 8:34 PM, Martin Sustrik <[email-masked]> wrote:

> iQEcBAEBAgAGBQJTflFfAAoJENTpVjxCNN9YfTMH/RhB8m9X4JPi2ykekLTsGY7m
> gMzr/4hi9dpWzjrD6m5dgxh3XiKl5heB2RH4nyX6JtH7fgD43a+LMLF3Y6z8KrXF
> cUmXu+kyhoCOOMS7oIRD8RMWXLQticHKZznNP9FYNH/LRLl2t8zmYJQgMdNGtYz4
> sXSDIJz7zjZl2hvOxDatjLpel/R2xUXLhEp3MFwEJDjQsazCyDahXjReoTVPoXKY
> leAMl+smVgk0HqpZVt+UJ/iDYczmh/VFtwTulw2Ky1x+5rqKl1c2sxIy0VMeUsoU
> s51yWQLedEDQWGG/pyB8EMnw0UnIL3+Tv6zMWKX7rEfCavEoRLApS/zudyA1vY4=
> =Fgk+

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 May 2014 09:34:05 +0200

+1

=> very interesting but beyond.

On 27. mai 2014, at 09:32, Jon Crowcroft wrote:

> totally agree - I think generalized pattern approach is really nice, and we tried using it in the "building blocks" structure that was used in the RMT group - i think quite successfully
> 
> however, patterns (and RMT consierations too) are over-reach for TAPS, in my opinion....life's too short to get something done that new, big, and complex (and contentious in some quarters)
> 
>

---

From: Martin Sustrik <[email-masked]>
Date: Tue, 27 May 2014 10:19:58 +0200

On 27/05/14 09:32, Jon Crowcroft wrote:
> totally agree - I think generalized pattern approach is really
> nice, and we tried using it in the "building blocks" structure that
> was used in the RMT group - i think quite successfully
> 
> however, patterns (and RMT consierations too) are over-reach for
> TAPS, in my opinion....life's too short to get something done that
> new, big, and complex (and contentious in some quarters)

Still, do you know whether there's a place where that kind of stuff is
discussed? I wanted to create such working group within IETF once,
even spoke to Peter Saint-Andre who was directort of application area
back then, but nothing have materialised in the end.

Martin

---

From: Toby Moncaster <[email-masked]>
Date: Tue, 27 May 2014 09:32:41 +0100

Would this be the sort of thing that could live in the IRTF? It would give it more freedom…

Toby

On 27 May 2014, at 09:19, Martin Sustrik <[email-masked]> wrote:

> iQEcBAEBAgAGBQJThEquAAoJENTpVjxCNN9YUlYH/jotPSYDIVE8I4FPjduzwrQx
> L4KAgFvREKG9QiaTL0alnKdBQHm+pA3eq7Es1FwMjw5SleCt54ZffwyggjqNXHiN
> jBLBa8/XzBmpoXPpm8fG9FlM4c2GLLgU+itxTp3kvM4jL6ZxUJW7bf/lde/EWogF
> IA9SAR63hqvUIOB1BrW5poGP7N1UKPsD2DPohGUkMnlJVRpM6iTk5s4iId8BqTsc
> ub8tpL4QnEWkihxYJd90bJI48RDaNu819bRzDYIVcKDiByRw2ErqfPI0q761awuQ
> Y60gzy7/4Ejw/1tRWLW0NVUMqcwd3FVmPIWdlZ9qdhJebWEcFD/1SsAzMc5/bzI=
> =qpyn

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 27 May 2014 10:35:46 +0100

Martin

I think the ietf (and even to some extent the irtf) is inimicable to
computer science:)
 >>-----END PGP SIGNATURE-----

 cheers

   jon

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 27 May 2014 08:53:34 -0500

So, it may be useful for me to chime in here. I'm speaking only as 
1/16th of the IESG, of course.

I thought the TAPS BoF in London was very helpful, and the IESG and IAB 
spent a significant amount of time talking about what happened at the 
BoF (thanks to Michael and Murray for capable chairing, and to Michael 
for producing near-verbatim minutes from the recorded audio), both at 
the "week in review" session on Friday afternoon after IETF 89, and at 
the joint IESG/IAB retreat a couple of weeks ago.

There's a lot to talk about, and the folks who observed that IETF 
working groups are a lousy place to talk about things, especially at 
charter time, are dead-on.

So what I'm asking, is that people take a shot at proposing a minimal 
charter that we could approve quickly (and maybe without a BOF - they 
aren't required, and we're trying to make it easier for people to start 
work).

We'll find venues for work that needs to happen, whether in IETF working 
groups, in IRTF research groups, or as Independent Submissions, and I'm 
happy to sponsor mailing lists for various chunks of this work as you 
identify them, so you don't have to have one big conversation about the 
Answer to Life, the Universe, and Everything (c).

So please, talk amongst yourselves, and see what you can agree on :-)

Spencer

On 05/27/2014 02:32 AM, Jon Crowcroft wrote:
> totally agree - I think generalized pattern approach is really nice, 
> and we tried using it in the "building blocks" structure that was used 
> in the RMT group - i think quite successfully
>
> however, patterns (and RMT consierations too) are over-reach for TAPS, 
> in my opinion....life's too short to get something done that new, big, 
> and complex (and contentious in some quarters)

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 May 2014 16:11:50 +0200

Thanks a lot Spencer!

TAPS: please stay tuned for a first proposal coming from me very soon - this incorporates some prior discussion that we probably don't want to re-iterate and wouldn't want to incorporate in the current charter - you heard the man: "a minimal charter that we could approve quickly", so this is about removing things that we wanted to do from *this* charter, and hoping / expecting that they will be dealt with elsewhere.

Cheers
Michael

On 27. mai 2014, at 15:53, Spencer Dawkins wrote:

> So, it may be useful for me to chime in here. I'm speaking only as 1/16th of the IESG, of course.
> 
> I thought the TAPS BoF in London was very helpful, and the IESG and IAB spent a significant amount of time talking about what happened at the BoF (thanks to Michael and Murray for capable chairing, and to Michael for producing near-verbatim minutes from the recorded audio), both at the "week in review" session on Friday afternoon after IETF 89, and at the joint IESG/IAB retreat a couple of weeks ago.
> 
> There's a lot to talk about, and the folks who observed that IETF working groups are a lousy place to talk about things, especially at charter time, are dead-on.
> 
> So what I'm asking, is that people take a shot at proposing a minimal charter that we could approve quickly (and maybe without a BOF - they aren't required, and we're trying to make it easier for people to start work).
> 
> We'll find venues for work that needs to happen, whether in IETF working groups, in IRTF research groups, or as Independent Submissions, and I'm happy to sponsor mailing lists for various chunks of this work as you identify them, so you don't have to have one big conversation about the Answer to Life, the Universe, and Everything (c).
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 May 2014 21:38:05 +0200

Hi all,

Following up on this, please take a look at:
https://sites.google.com/site/transportprotocolservices/charter-proposal

I'd like to suggest this as a way forward to the group; could you support this as a Charter for forming a WG?

I think it's clear to all of us that there should be more work beyond this, but it is important that the initial goals are clear and attainable. Work beyond could take various forms, in various places - note how Spencer wrote "We'll find venues for work that needs to happen". This new proposed charter is about having a common starting point that we all can agree on.

Cheers,
Michael

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 27 May 2014 22:13:53 +0200

Hi Michael,

I agree with your proposal as a good common starting point.

One detail on the deliverables: In the first bullet identifying 
available services it says "IETF transport protocols and congestion 
control mechanisms" in the third bullet on providing services it says 
"IETF transports". Should the third bullet not also be "IETF transports 
and congestion control mechanisms" to be consistent? (Alternatively the 
first bullet should be revised.)

Also, you lost some text (or missed to remove): "The Working Group will 
coordinate closely with groups."

Cheers,
Anna

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 08:35:38 +0200

Hi,

> I agree with your proposal as a good common starting point. 

Great!  Others - in case you also agree, please say it out loud too - I think we want to get a general idea of the group's perception as soon as possible now.

> One detail on the deliverables: In the first bullet identifying available services it says "IETF transport protocols and congestion control mechanisms" in the third bullet on providing services it says "IETF transports". Should the third bullet not also be "IETF transports and congestion control         mechanisms" to be consistent? (Alternatively the first bullet should be revised.)

Not 100% sure which bullet you mean, but I think anyway the answer is no: the first is about identifying services, the third (deliverable / milestone) is about how to provide them. You need a protocol to provide a service.

> Also, you lost some text (or missed to remove): "The Working Group will coordinate closely with groups."

Fixed

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Wed, 28 May 2014 08:55:30 +0200

hi Michael,

+1 to everything Anna said; the present proposal strikes a good balance between what can be immediately useful in this space and what we already know how to do. I would make one point on your edit, though...

>> Also, you lost some text (or missed to remove): "The Working Group will coordinate closely with groups."

Coordination is not just important with other Working Groups, but with possible Research Groups in the IRTF as well, since lots of things we suspect we want to do but which aren't cooked enough to do engineering on yet could be referred to a future RG.

Cheers,

Brian

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 28 May 2014 08:58:58 +0100

so good in general & +1 to Anna's comments, but also
the "work" is all about discovering what protocol services might be
available - shouldn't there be at least a stab at how to "select or engage"
one (or more) appropriately? I mean knowing how to speak 3 languages is
fine, but not being able to choose which one to speak when trying to talk
to someone is a bit, err, dumbing down:)

my 3 zlotys

On Tue, May 27, 2014 at 8:38 PM, Michael Welzl <[email-masked]> wrote:

> I think it's clear to all of us that there should be more work beyond
> this, but it is important that the initial goals are clear and attainable.
> Work beyond could take various forms, in various places - note how Spencer
> wrote "We'll find venues for work that needs to happen". This new proposed
> charter is about having a common starting point that we all can agree on.
>
> Cheers,
> Michael
>
>
>
> > TAPS: please stay tuned for a first proposal coming from me very soon -
> this incorporates some prior discussion that we probably don't want to
> re-iterate and wouldn't want to incorporate in the current charter - you
> heard the man: "a minimal charter that we could approve quickly", so this
> is about removing things that we wanted to do from *this* charter, and
> hoping / expecting that they will be dealt with elsewhere.
> >
> > Cheers
> > Michael
> >
> >
> >
> spent a significant amount of time talking about what happened at the BoF
> (thanks to Michael and Murray for capable chairing, and to Michael for
> producing near-verbatim minutes from the recorded audio), both at the "week
> in review" session on Friday afternoon after IETF 89, and at the joint
> IESG/IAB retreat a couple of weeks ago.
> >>
> >> We'll find venues for work that needs to happen, whether in IETF
> working groups, in IRTF research groups, or as Independent Submissions, and
> I'm happy to sponsor mailing lists for various chunks of this work as you
> and we tried using it in the "building blocks" structure that was used in
> the RMT group - i think quite successfully
> >>>
> in my opinion....life's too short to get something done that new, big, and

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 28 May 2014 04:12:20 -0400

I agree with the charter and Anna's comments but as John mentioned 
there should
be a stab at suggesting a solution.

/mjm

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 10:16:36 +0200

So, first things first: everyone seems to agree with Anna, but what about my negative response to her comment about making the bullets consistent?

It makes sense to identify services provided by transport protocols & congestion control mechanisms. I don't think it makes sense to specify how services can be provided using ... congestion control mechanisms, as cc. mechanisms need to be implemented within a transport protocol, of which they are a (sometimes configurable) part. You need a protocol to provide a service.

Agreed?

(sure, this is just a nit, but I don't want to go against the general perception here)

On 28. mai 2014, at 10:12, Marie-Jose Montpetit <[email-masked]> wrote:

> I agree with the charter and Anna's comments but as John mentioned there should

---

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

> Coordination is not just important with other Working Groups, but with possible Research Groups in the IRTF as well, since lots of things we suspect we want to do but which aren't cooked enough to…

done, I added: "and/or IRTF Research Groups".

This strikes me as a good opportunity to mention a detail that is easily missed: the charter of IRTF ICCRG includes:
"Because congestion control is typically a key function of transport protocols, it is hard to separate other transport layer issues from congestion control. Considerations for deployment of transport protocols are therefore also considered within scope. "

Not many documents are published via ICCRG, we currently function more like a forum for presentations of things that are not ready for the IETF yet. With ICCRG chair hat on, TAPS-related work would be very welcome in ICCRG, if only to provide a forum until a dedicated RG exists (if that really should be needed, i.e. if ICCRG couldn't generally fill that gap? I think that in ICCRG, the right people are already on the list and in the room when we meet).

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 10:27:47 +0200

So - maybe this is just me being stupid, but are we talking about "selecting and engaging" a protocol or a service here, i.e. something "under the hood" or a guidance document that says "for this, you want that" ?

Actual wording suggestions are very welcome   :)

---

From: [email-masked]
Date: Wed, 28 May 2014 10:09:13 +0100

Maybe I misunderstood, but I thought:

"Informational RFC summarizing the services" was a little about guidance
that says amongst things "for this, you want that" (if it is supported)

and

"Experimental RFC specifying how the defined transport services can be
provided" was about "selecting and engaging" a protocol that will select
and deliver a service in an actual network

Gorry

> So - maybe this is just me being stupid, but are we talking about
> "selecting and engaging" a protocol or a service here, i.e. something
> "under the hood" or a guidance document that says "for this, you want
> that" ?
>
>>>> I'd like to suggest this as a way forward to the group; could you
>>>> support
>>>> this as a Charter for forming a WG?
>>>>
>>>> BoF
>>>> nice,
>>>> in
>>>> TAPS,
>>>> and

---

From: Toby Moncaster <[email-masked]>
Date: Wed, 28 May 2014 10:28:33 +0100

What Gorry says seems to make sense, and perhaps should be made explicit?

Regarding the issue of apparent inconsistency between bullets one and three. I think this highlights that one of the things we should be seeking to do early on is disambiguate all the terminology relating to transport protocols, transport mechanisms, congestion control mechanisms, transport services, etc.

Final point. Deliverable 2 “Proposed Standard RFC specifying a set of transport services that an end system should provide”. We need to be careful about this one. If it is going to be a proposed standard then really it needs to specify some things as must provide. There is a chance that we’ll get complaints about using “should” in the bullet? I’m assuming we are intending that this should look something like RFC1812 Requirements for IPv4 Routers? But I may be wrong

Toby

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 28 May 2014 10:28:39 +0100

that sounds 100% ok to me

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 14:25:51 +0200

Gorry's interpretation was also mine, which is why I didn't get what exactly you people want at first -

> What Gorry says seems to make sense, and perhaps should be made explicit?

Fine, yes - but I'd still welcome actual wording...

> Regarding the issue of apparent inconsistency between bullets one and three. I think this highlights that one of the things we should be seeking to do early on is disambiguate all the terminology r…

I agree, but I also take this to mean that you agree with not changing it.  (it's really only a nit anyway)

> Final point. Deliverable 2 “Proposed Standard RFC specifying a set of transport services that an end system should provide”. We need to be careful about this one. If it is going to be a proposed st…

Hm. But this is about future end systems - if we just replace "should" with "must" then we can only write "reliable byte stream" and "unreliable datagram service" in there  :-)
Thoughts?

Cheers,
Michael

---

From: [email-masked]
Date: Wed, 28 May 2014 14:07:28 +0100

I suggest three things:

(1) Shorten M14 - It's long for the tracker and the details are in the
Charter above: "M14: Submit specification of how the defined transport
services can be provided using IETF transports, including the definition
of mechanisms to discover the availability of protocols on an interface
(end system support and path support), to IESG as an Experimental RFC."
I suggest:
"M14: Submit specification of how the transport services can be provided
to IESG as an Experimental RFC."

(2) On the wording below, I suggest:
"Proposed Standard RFC specifying a set of transport services that end
systems need to provide"

(3) On the milestone below, I suggest:
"M13: Submit end system transport services to IESG as a Proposed Standard."

Please change as people see fit,

Gorry

>> Regarding the issue of apparent inconsistency between bullets one and
>> three. I think this highlights that one of the things we should be
>> seeking to do early on is disambiguate all the terminology relating to
>> transport protocols, transport mechanisms, congestion control
>> mechanisms, transport services, etc.
>
>> Final point. Deliverable 2 “Proposed Standard RFC specifying a set of
>> transport services that an end system should provide”. We need to be
>> careful about this one. If it is going to be a proposed standard then
>> really it needs to specify some things as must provide. There is a
>> chance that we’ll get complaints about using “should” in the bullet? I’m
>> assuming we are intending that this should look something like RFC1812
>> Requirements for IPv4 Routers? But I may be wrong
>
> Hm. But this is about future end systems - if we just replace "should"
> with "must" then we can only write "reliable byte stream" and "unreliable
> datagram service" in there  :-)
> Thoughts?
>
> Cheers,
> Michael
>

---

From: Toby Moncaster <[email-masked]>
Date: Wed, 28 May 2014 14:08:36 +0100

I agree with all three of these :)

Toby

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 28 May 2014 08:10:35 -0500

On 05/28/2014 01:55 AM, Brian Trammell wrote:
> hi Michael,
>
> +1 to everything Anna said; the present proposal strikes a good 
> balance between what can be immediately useful in this space and what 
> we already know how to do. I would make one point on your edit, though...

...

> Coordination is not just important with other Working Groups, but with 
> possible Research Groups in the IRTF as well, since lots of things we 
> suspect we want to do but which aren't cooked enough to do engineering 
> on yet could be referred to a future RG.

Brian, thanks for suggesting this edit (which Michael is picking up).

In addition to anything that ends up in the IRTF ... my understanding 
was that the IAB may end up with a program somewhere near the meta-TAPS 
space. Is it premature to call that out?

If the IAB does put a relevant program in place, I'd expect some 
interaction, and I'd rather not have to revise the charter to say so :-)

Thanks,

Spencer

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 28 May 2014 14:10:50 +0100

+1

On Wed, May 28, 2014 at 2:08 PM, Toby Moncaster <[email-masked]
> wrote:

> >> I agree, but I also take this to mean that you agree with not changing
> it.
> >> (it's really only a nit anyway)
> >>
> >>

---

From: Aaron Falk <[email-masked]>
Date: Wed, 28 May 2014 10:55:43 -0400

Again, I'm coming into the discussion a little late but I found the charter
a little hard to understand.  Others have tripped over the same thing I
think.  Likely easily solved with a little more preface.

   - The charter says the goal of the wg is 'identifying transport
   services' but that term isn't clearly defined. I think a definition needs
   to be in the charter (esp since it is the name of the wg).
   - 'Encapsulated transports' also needs a definition.
   - Without a distinction between a 'transport service' vs. protocols &
   congestion control mechanisms I can't make sense of working group goal #2.
     Or maybe the first clause should be deleted: ("Specify the definition of
   mechanisms to discover the availability of protocols on an interface (end
   system support and path support.")
   - Is the informational RFC just a catalog of protocols & congestion
   control mechanisms?  I thought the goal was more about finding the
   assembled combinations of such that are useful.

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 16:59:07 +0200

Done.

>that says amongst things "for this, you want that" (if it is supported)

I now addressed this by adding, under "The Working Group will:", where it says "identify services ...", the following sentence:
"The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service."

>and deliver a service in an actual network

I now addressed this by adding, under "The Working Group will:", where it says "Specify how ...", the following sentence:
"The resulting document will explain how to select and engage a protocol in order to deliver a transport service."

See: https://sites.google.com/site/transportprotocolservices/charter-proposal

Opinions?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 17:08:22 +0200

Hi Aaron,

Great input, thanks!!

On 28. mai 2014, at 16:55, Aaron Falk <[email-masked]> wrote:

> Again, I'm coming into the discussion a little late but I found the charter a little hard to understand.  Others have tripped over the same thing I think.  Likely easily solved with a little more preface.
> The charter says the goal of the wg is 'identifying transport services' but that term isn't clearly defined. I think a definition needs to be in the charter (esp since it is the name of the wg).
> 'Encapsulated transports' also needs a definition.
> Without a distinction between a 'transport service' vs. protocols & congestion control mechanisms I can't make sense of working group goal #2.   Or maybe the first clause should be deleted: ("Specify the definition of mechanisms to discover the availability of protocols on an interface (end system support and path support.") 

I agree about these things and will propose suitable fixes ASAP.

> Is the informational RFC just a catalog of protocols & congestion control mechanisms?  I thought the goal was more about finding the assembled combinations of such that are useful.  

I thought it should be such a catalog, and the (most) useful combinations would go into the proposed standard RFC.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 17:21:03 +0200

>> The charter says the goal of the wg is 'identifying transport services' but that term isn't clearly defined. I think a definition needs to be in the charter (esp since it is the name of the wg).
Proposal: add the following sentence as sentence 2 in the charter, i.e. after: "Conjointly, transport protocols such as 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 example, SCTP provides potentially faster reliable delivery for applications that can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication.
***

It's definition by example, but it should make it pretty clear what is meant?

>> 'Encapsulated transports' also needs a definition.

I suggest to include, right after "Encapsulated transports:
***
(e.g., SCTP over UDP)
***

>> Without a distinction between a 'transport service' vs. protocols & congestion control mechanisms I can't make sense of working group goal #2.   Or maybe the first clause should be deleted: ("Spec…

Given the above (or similar) changes, do you still think it's needed to remove the clause? I like your changed sentence, but in context it might make the reader wonder "why do they do that?" because the reason is now gone.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Wed, 28 May 2014 17:23:50 +0200

On 28 May 2014, at 17:08, Michael Welzl <[email-masked]> wrote:

>> 	• The charter says the goal of the wg is 'identifying transport services' but that term isn't clearly defined. I think a definition needs to be in the charter (esp since it is the name of the wg).
>> 	• 'Encapsulated transports' also needs a definition.
>> 	• Without a distinction between a 'transport service' vs. protocols & congestion control mechanisms I can't make sense of working group goal #2.   Or maybe the first clause should be deleted: ("Specify the definition of mechanisms to discover the availability of protocols on an interface (end system support and path support.") 
> 
>> 	• Is the informational RFC just a catalog of protocols & congestion control mechanisms?  I thought the goal was more about finding the assembled combinations of such that are useful.  
> 

It might (eventually) make sense to publish these as a single document.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 17:33:44 +0200

> It might (eventually) make sense to publish these as a single document.

Not sure what you're suggesting. In my mind (but maybe we have a different interpretation?), we first have the Informational RFC, which is long. Then, the Proposed Standard, which is essentially a shortened version of the Informational RFC.

What you say is that we should eventually combine them into one document?

=> you mean a long document, where the key combinations are marked as such?  Yes this might make sense, or it might just be a very long document that noone wants to read. - again, I'll point to page 51 of this document: http://heim.ifi.uio.no/~michawe/teaching/dipls/stefan_joerer.pdf   - one can imagine that the list in the Informational RFC would be 1) much longer, 2) much more detailed.

My suggestion: possibly write such a document, but decide that later, as (if) we recharter. Ok?  If so, do you want me to insert this in the sentence about rechartering?  (I wouldn't, as we'd really only see at the end of the work if this makes sense or not, and as I said I suspect the outcome will be negative, just because of the sheer length of the result - but fine with me either way).

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Wed, 28 May 2014 12:13:35 -0400

On Wed, May 28, 2014 at 11:21 AM, Michael Welzl <[email-masked]> wrote:

> Again, I'm coming into the discussion a little late but I found the
> charter a little hard to understand.  Others have tripped over the same
> thing I think.  Likely easily solved with a little more preface.
>
> Proposal: add the following sentence as sentence 2 in the charter, i.e.
> after: "Conjointly, transport protocols such as 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. "
>
>
How about  "Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend the number of
transport services to applications in addition to the long-standing two
services provided by TCP and UDP. "  I think it is clearer if 'transport
services" is explicitly used.

> ***
> For example, SCTP provides potentially faster reliable delivery for
> applications that can accept blocks of data out of order, and LEDBAT
> provides low-priority "scavenger" communication.
> ***
>

it's a good example.

> I suggest to include, right after "Encapsulated transports:

Right.  Very helpful.

> Given the above (or similar) changes, do you still think it's needed to
> remove the clause? I like your changed sentence, but in context it might
> make the reader wonder "why do they do that?" because the reason is now
> gone.
>

It's worth motivating that task.  how about adding "to provide a basis for
incremental deployment"?  My preference is to remove the clause because it
adds ambiguity.  YMMV.

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 19:04:16 +0200

On 28. mai 2014, at 18:13, Aaron Falk <[email-masked]> wrote:

> How about  "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the number of transport services to applications in addition to the long-standing two services provided by TCP and UDP. "  I think it is clearer if 'transport services" is explicitly used.

done

> It's definition by example, but it should make it pretty clear what is meant?

inserted

> I suggest to include, right after "Encapsulated transports:

... but now deleted because I went with your update below which removes the whole bit of encapsulated transports -

> It's worth motivating that task.  how about adding "to provide a basis for incremental deployment"?  My preference is to remove the clause because it adds ambiguity.  YMMV.

done (and changed "specify the definition of mechanisms" to "specify mechanisms", I think this was a leftover from the previous text where it said "the definition"). So the final text for goal #2 now reads:

"	• To provide a basis for incremental deployment, specify mechanisms to discover the availability of protocols on an interface (end system support and path support). The resulting document will explain how to select and engage a protocol in order to deliver a transport service."

and the full beast is at:
https://sites.google.com/site/transportprotocolservices/charter-proposal

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Wed, 28 May 2014 19:05:26 +0200

hi Michael,

the short short answer here is that the scope of work is much more important than the actual division of content across individual documents (indeed, I'd leave the deliverables list out of the charter text, and put the actual documents only in the milestones, but maybe that's just me).

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2014 19:11:12 +0200

On 28. mai 2014, at 19:05, Brian Trammell <[email-masked]> wrote:

> hi Michael,
> 
> the short short answer here is that the scope of work is much more important than the actual division of content across individual documents

Sure! Any comments about the scope as it's now written?

> (indeed, I'd leave the deliverables list out of the charter text, and put the actual documents only in the milestones, but maybe that's just me).

I think I'll leave them as they are because:
- Gorry has already made me shorten the text on a milestone because it's long for the tracker
- your suggestion would make them longer again
- at the same time you seem to indicate that you don't care much about this detail, so this seems to be the easiest solution for me.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Thu, 29 May 2014 09:37:49 +0200

> Sure! Any comments about the scope as it's now written?

Scope looks good. Tiny English comment: the structure of the points should be parallel, so I'd edit point 2 to read:

	• specify mechanisms to discover the availability of protocols on an interface (end system support and path support), in order to provide a basis for incremental deployment. The resulting document will explain how to select and engage a protocol in order to deliver a transport service.

I'd also drop the point in the deliverables about rechartering to do an example API. The working group could recharter to do lots of things. If you want the text in the charter to head off questions about "why aren't we doing this", I'd suggest adding a new list beginning with "The following topics are currently out of scope for this Working Group, but may be addressed in a future charter:"

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 11:25:50 +0200

On 29. mai 2014, at 09:37, Brian Trammell <[email-masked]> wrote:

> Scope looks good.

Great!

> Tiny English comment: the structure of the points should be parallel, so I'd edit point 2 to read:
> 

done

> I'd also drop the point in the deliverables about rechartering to do an example API. The working group could recharter to do lots of things. If you want the text in the charter to head off question…

Okay; out of these two options, I chose removing the sentence.
(I see that a list as you suggest would make more sense than having this single item, but then again, creating a list on possible future work seems unnecessary at this stage - we'd end up getting into a long debate on our potential future visions, which we wanted to avoid with this charter in the first place.)

Cheers,
Michael

---

From: [email-masked]
Date: Thu, 29 May 2014 10:28:56 +0100

(1) I did like the list of deliverables in the description when the group
was talking about a BOF.

However, I'd agree with Brian T's point that an actual working group
charter is best not to include this list. So, I suggest to remove the
entire list, and instead just adjust the plain-text describing what the WG
will do. Reading again,  I think all that is needed could be adding one
final sentence about the last work item to the two existing bullets, i.e.
something like:

"• define a set of Experimental mechanisms to discover the availability of
protocols on an interface (both end and path support)."

Would that work?

(2) I'd also agree with omitting the re-charter line. The scope is now clear.

(3) Finally, I think the non-goal concerning tunnels on the last line
should be clearer. I suggest the out-of-scope items are actually:

"The following topics are out of scope of this Working Group:

• mechanisms to specify Quality-of-Service (QoS).
• definition of new encapsulations and tunneling mechanisms."

- My rationale is that any new specs would seem like tsvwg work (or at
least not this group) -- but working with any existing specs could
possibly be in scope? At least existing specs that  directly encapsulate
transport protocols.

Gorry

-

> hi Michael,
>
> the short short answer here is that the scope of work is much more
> important than the actual division of content across individual documents
> (indeed, I'd leave the deliverables list out of the charter text, and put
> the actual documents only in the milestones, but maybe that's just me).
>
> Cheers,
>
> Brian
>
>>>>> charter a little hard to understand.  Others have tripped over the
>>>>> same thing I think.  Likely easily solved with a little more preface.
>>>>> 	• The charter says the goal of the wg is 'identifying transport
>>>>> services' but that term isn't clearly defined. I think a definition
>>>>> needs to be in the charter (esp since it is the name of the wg).
>>>>> 	• Without a distinction between a 'transport service' vs. protocols
>>>>> & congestion control mechanisms I can't make sense of working group
>>>>> goal #2.   Or maybe the first clause should be deleted: ("Specify
>>>>> the definition of mechanisms to discover the availability of
>>>>> protocols on an interface (end system support and path support.")
>>>>
>>>>> 	• Is the informational RFC just a catalog of protocols & congestion
>>>> I thought it should be such a catalog, and the (most) useful
>>>> combinations would go into the proposed standard RFC.
>>>
>> Not sure what you're suggesting. In my mind (but maybe we have a
>> different interpretation?), we first have the Informational RFC, which
>> is long. Then, the Proposed Standard, which is essentially a shortened
>> version of the Informational RFC.
>>
>> => you mean a long document, where the key combinations are marked as
>> such?  Yes this might make sense, or it might just be a very long
>> document that noone wants to read. - again, I'll point to page 51 of
>> this document:
>> http://heim.ifi.uio.no/~michawe/teaching/dipls/stefan_joerer.pdf   - one
>> can imagine that the list in the Informational RFC would be 1) much
>> longer, 2) much more detailed.
>>
>> My suggestion: possibly write such a document, but decide that later, as
>> (if) we recharter. Ok?  If so, do you want me to insert this in the
>> sentence about rechartering?  (I wouldn't, as we'd really only see at
>> the end of the work if this makes sense or not, and as I said I suspect
>> the outcome will be negative, just because of the sheer length of the
>> result - but fine with me either way).
>>
>> Cheers,
>> Michael
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 12:33:42 +0200

On 29. mai 2014, at 11:28, [email-masked] wrote:

> will do.

Fine by me - as I wrote before, I left the text in there because I thought this is how charters typically are written (but I have very limited experience there). So ok, I'll cut it.

> Reading again,  I think all that is needed could be adding one

Fine in principle, and I see the point, but this sounds like a repetition of the second bullet in the list. I propose the following complete text for the "The Working Group will:" bullets (I think it maps well to the existing milestones):

***

• identify services provided by existing IETF transport protocols and
congestion control mechanisms, based on Standards-track and Experimental
RFCs that were developed in the IETF's Transport Area.

* specify a set of transport services that end systems need to provide and
provide guidance on making a choice among available mechanisms and
protocols to obtain a certain transport service.

• specify experimental mechanisms as a basis for incremental deployment to
discover the availability of protocols on an interface (both end system and path
support). This will explain how to select and engage a protocol to deliver
a transport service.

***

ok?

> (2) I'd also agree with omitting the re-charter line. The scope is now clear.

Good; I have already applied that change.

> possibly be in scope? At least existing specs that  directly encapsulate

Fine by me. As for applying existing encapsulating / tunneling mechanisms, just because "native and encapsulated transports" isn't there anymore I don't think there's anything in the charter that restrains it to only native transports  (e.g., SCTP over UDP etc. could definitely be used?!).

Cheers,
Michael

---

From: [email-masked]
Date: Thu, 29 May 2014 11:49:29 +0100

If others are content, I'd be happy with your proposed text.

Gorry

> Fine by me - as I wrote before, I left the text in there because I thought
> this is how charters typically are written (but I have very limited
> experience there). So ok, I'll cut it.
>
>
> Fine in principle, and I see the point, but this sounds like a repetition
> of the second bullet in the list. I propose the following complete text
> for the "The Working Group will:" bullets (I think it maps well to the
> existing milestones):
>
> ***
>
> Fine by me. As for applying existing encapsulating / tunneling mechanisms,
> just because "native and encapsulated transports" isn't there anymore I
> don't think there's anything in the charter that restrains it to only
> native transports  (e.g., SCTP over UDP etc. could definitely be used?!).
>
> Cheers,
> Michael
>

---

From: Toby Moncaster <[email-masked]>
Date: Thu, 29 May 2014 11:54:23 +0100

I have one question - do we need to specify “that were developed in the IETF’s Transport Area”? Could we make it “were developed in the IETF”

I might re-word bullet two to:

“specify a set of transport services that end systems need to provide and
provide guidance on choosing among available mechanisms and
protocols to obtain a given transport service."

Other than that that I’m happy with the text

Toby

---

From: [email-masked]
Date: Thu, 29 May 2014 12:04:05 +0100

See inline

> I have one question - do we need to specify “that were developed in the
> IETF’s Transport Area”? Could we make it “were developed in the IETF”
>
Would work for me too -- but I do think the work should be confined to
transport protocols in the IETF.

> protocols to obtain a given transport service."
That would also be OK

>>>> entire list, and instead just adjust the plain-text describing what
>>>> the
>>>> WG
>>>> will do.
>>>
>>>> "• define a set of Experimental mechanisms to discover the
>>>> availability
>>>> of

---

From: Anna Brunstrom <[email-masked]>
Date: Thu, 29 May 2014 13:22:20 +0200

Hi,

I think you lost Brian's update related to bullet three. I think it 
would be more clear to say:

"specify experimental mechanisms to discover the availability of 
protocols on an interface (both end system
and path support), in order to provide a basis for incremental 
deployment. This will explain how to select and engage a protocol to deliver
a transport service."

Toby's update for bullet two looks good to me. I also agree with Gorry 
that the work should be confined to transport protocols in the IETF.

Anna

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 13:56:33 +0200

Hi,

>transport protocols in the IETF.

This is the original sentence that we're talking about:

***
identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs that were developed in the IETF's Transport Area.
***

The proposal of Toby was to not limit the RFCs to the IETF's *Transport Area*. Changing this text to "in the IETF" makes it redundant, as "IETF transport protocols" is already there anyway. So I now changed it to:

***
identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs.
***

I changed this in the text and incorporated all the other suggested changes, please check at
https://sites.google.com/site/transportprotocolservices/charter-proposal
if I didn't make a mistake.

At least one person told me about problems reaching the page, so I'm copying the whole text in at the end of this email too.

Cheers,
Michael

******

Transport Services (TAPS)

Status: Proposed Working Group
Last Updated: 2014-05-29

Chair(s):
TBD

Transport Area Director(s):
Spencer Dawkins <[email-masked]>
Martin Stiemerling <[email-masked]>

Transport Area Advisor:
TBD

Mailing Lists: [email-masked]

Description of Working Group

Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the number of transport services to applications in addition to the long-standing two services provided by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications that can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. For an application programmer, it is hard to use protocols other than TCP or UDP: not all protocols are available everywhere, hence a fall-back solution to e.g. TCP or UDP 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.

There are many ways in which this problem could be addressed; while it may not yet be clear what the best way forward could be, any approach to provide a richer set of transport services to applications will have to begin with the identification of the services that current transport protocols provide.

The Working Group will:
	• identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service.
	• specify a set of transport services that end systems need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service.
	• specify experimental mechanisms to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment. This will explain how to select and engage a protocol to deliver a transport service.

The Working Group will coordinate closely with other Working Groups and/or IRTF Research Groups.

The following topics are out of scope of this Working Group:
	• Quality-of-Service (QoS) and tunneling mechanisms and services
	• Definition of new encapsulations and tunneling mechanisms

Deliverables:
	• Informational RFC summarizing the services provided by IETF transport protocols and congestion control mechanisms
	• Proposed Standard RFC specifying a set of transport services that end systems need to provide
	• Experimental RFC specifying how the defined transport services can be provided using IETF transports, including the definition of mechanisms to discover the availability of protocols on an interface (end system support and path support).

Milestones:
	• M7: Submit summary of the services provided by IETF transport protocols and congestion control mechanisms to IESG as an Informational RFC.
	• M13: Submit end system transport services to IESG as a Proposed Standard.
	• M14: Submit specification of how the transport services can be provided to IESG as an Experimental RFC.

---

From: Toby Moncaster <[email-masked]>
Date: Thu, 29 May 2014 13:01:24 +0100

final nit… I think we should say 

“…coordinate closely with other Working Group and IRTF Research Groups.” (not and/or)

Also wasn’t Spencer encouraging us to mention potential IAB interaction? In which case this would be the sentence to say that in…

Toby

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 May 2014 14:09:35 +0200

> identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs.
Just to double check: We obviously want to exclude Historic RFCs. Is the same
true for Informational ones?

Best regards
Michael

---

From: [email-masked]
Date: Thu, 29 May 2014 13:11:30 +0100

Maybe the IAB don't need a specific mention here? - If they do work it'll
become visible and I am sure we can coordinate - including it seems like
the group somehow needs to take specific notice of something.

Gorry

> Also wasn’t Spencer encouraging us to mention potential IAB interaction?
> In which case this would be the sentence to say that in…
>
> Toby
>
>> identify services provided by existing IETF transport protocols and
>> The proposal of Toby was to not limit the RFCs to the IETF's *Transport
>> Area*. Changing this text to "in the IETF" makes it redundant, as "IETF
>> transport protocols" is already there anyway. So I now changed it to:
>>
>> ***
>> identify services provided by existing IETF transport protocols and
>> RFCs.
>> At least one person told me about problems reaching the page, so I'm
>> copying the whole text in at the end of this email too.
>>
>> Cheers,
>> Michael
>>
>> ******
>>
>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and
>> the LEDBAT congestion control mechanism extend the number of transport
>> provided by TCP and UDP. For example, SCTP provides potentially faster
>> reliable delivery for applications that can accept blocks of data out of
>> order, and LEDBAT provides low-priority "scavenger" communication. For
>> an application programmer, it is hard to use protocols other than TCP or
>> UDP: not all protocols are available everywhere, hence a fall-back
>> solution to e.g. TCP or UDP 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.
>>
>> There are many ways in which this problem could be addressed; while it
>> may not yet be clear what the best way forward could be, any approach to
>> provide a richer set of transport services to applications will have to
>> begin with the identification of the services that current transport
>> protocols provide.
>>
>> The Working Group will:
>> congestion control mechanisms, based on Standards-track and
>> Experimental RFCs. The resulting document will provide guidance on
>> making a choice among available mechanisms and protocols to obtain a
>> certain transport service.
>> 	• specify a set of transport services that end systems need to provide
>> and provide guidance on choosing among available mechanisms and
>> protocols to obtain a given transport service.
>> 	• specify experimental mechanisms to discover the availability of
>> protocols on an interface (both end system and path support), in order
>> to provide a basis for incremental deployment. This will explain how to
>> select and engage a protocol to deliver a transport service.
>>
>> 	• Informational RFC summarizing the services provided by IETF transport
>> protocols and congestion control mechanisms
>> 	• Experimental RFC specifying how the defined transport services can be
>> provided using IETF transports, including the definition of mechanisms
>> to discover the availability of protocols on an interface (end system
>> support and path support).
>>
>> Milestones:
>> 	• M7: Submit summary of the services provided by IETF transport
>> protocols and congestion control mechanisms to IESG as an Informational
>> RFC.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 14:13:57 +0200

> “…coordinate closely with other Working Group and IRTF Research Groups.” (not and/or)

fixed

> Also wasn’t Spencer encouraging us to mention potential IAB interaction? In which case this would be the sentence to say that in…

Since I don't think I'm the right person to decide whether the IAB should be mentioned or not I'll see what happens on the list upon Gorry's response before incorporating text on that.

Cheers,
Michael

---

From: [email-masked]
Date: Thu, 29 May 2014 13:16:25 +0100

I'd suspect we don't need to go adding wording about INFO specs. The
important thing the group needs to include the standards-track methods.

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 May 2014 14:55:08 +0200

> important thing the group needs to include the standards-track methods.
Standards track RFCs are as clear as Historic ones. However, experimental
are explicitly covered, that is why I wanted to bring up informational
ones... I just want to make sure that the selection is on purpose...

Best regards
Michael

---

From: [email-masked]
Date: Thu, 29 May 2014 14:05:43 +0100

I'm not sure I understand the point -  are there specific INFO RFCs that
describe non-standards track RFCs that the group should consider?

I think the group should prioritise IETF-reviewed specs and wouldn't
particularly like to see too much focus on proprietary documented
protocols (such things are typically published as AD-sponsored INFO
documents in the RFC series).

Gorry

>>>> Experimental
>>>> Experimental
>>> Just to double check: We obviously want to exclude Historic RFCs. Is
>>> the
>>> same
>>>> 	• Proposed Standard RFC specifying a set of transport services that
>>>> end
>>>> systems need to provide

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 May 2014 15:15:21 +0200

> describe non-standards track RFCs that the group should consider?
I'm not aware of any... But I haven't done the scan...
I just saw that the scope was made wider: from RFCs coming from
TSV area to all RFCs. So I just wanted to make sure the exclusion
of Informational ones is still valid. That's all.
> documents in the RFC series).
That is fine... So it seems the selection is still on purpose.

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 15:31:25 +0200

On 29. mai 2014, at 15:15, Michael Tuexen <[email-masked]> wrote:

> TSV area to all RFCs.

I don't think it's actually a (much?) wider scope: after all it's only about "transport protocols and congestion control mechanisms".

BTW given the previous discussion on multicast where I think we ended up agreeing that we exclude it for now, shall we include the word "unicast" in this sentence??

> So I just wanted to make sure the exclusion

I dug through the archives:
https://sympa.uio.no/ifi.uio.no/arc/transport-services
to see what caused this restraint on Experimental / Standards Track. We had a discussion in September 2013 that led to it. This discussion started with the proposal to limit not necessarily to RFCs but to things that are out there and widely deployed. We then discussed how to define "widely deployed" - and this culminated in deciding that we go with standards track RFCs. Then, this was extended to include Experimental RFCs too, because some of them are in fact widely deployed too. We never discussed including Informational, and we should probably keep the constraint.

Cheers,
Michael

---

From: [email-masked]
Date: Thu, 29 May 2014 14:41:17 +0100

I'd personally avoid constraining the Charter to unicast (it's not
essential to progress and in principle multicast could be included in
future, say if enough expertise and a good use-case established) we could
constrain the milestones to exclude multicast, but not sure we even need
to explicitly state this.

Gorry

> I don't think it's actually a (much?) wider scope: after all it's only
> about "transport protocols and congestion control mechanisms".
>
> BTW given the previous discussion on multicast where I think we ended up
> agreeing that we exclude it for now, shall we include the word "unicast"
> in this sentence??
>
>
> to see what caused this restraint on Experimental / Standards Track. We
> had a discussion in September 2013 that led to it. This discussion started
> with the proposal to limit not necessarily to RFCs but to things that are
> out there and widely deployed. We then discussed how to define "widely
> deployed" - and this culminated in deciding that we go with standards
> track RFCs. Then, this was extended to include Experimental RFCs too,
> because some of them are in fact widely deployed too. We never discussed
> including Informational, and we should probably keep the constraint.
>
> Cheers,
> Michael
>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 May 2014 16:23:09 +0200

> I don't think it's actually a (much?) wider scope: after all it's only about "transport protocols and congestion control mechanisms".
Some people use transport protocol in other semantics as we do:
http://tools.ietf.org/html/rfc3550
> to see what caused this restraint on Experimental / Standards Track. We had a discussion in September 2013 that led to it. This discussion started with the proposal to limit not necessarily to RFCs…
OK. See let's keep it that way.

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 16:25:52 +0200

> http://tools.ietf.org/html/rfc3550

Argh YES!!!!   VERY good point!  Can we please put the TSV area constraint back in? It was there for a reason...

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 17:15:13 +0200

Fine by me to leave things as they are; it was just a thought.  True, if the expertise is there, we may not want to exclude it.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 29 May 2014 16:15:45 +0000

On 5/29/14, 8:25 AM, "Michael Welzl" <[email-masked]> wrote:

>Argh YES!!!!   VERY good point!  Can we please put the TSV area
>constraint back in? It was there for a reason...

I'd see that as an unnecessary parochialism.  RTP has ideas.  DTLS has
ideas.  BEEP has ideas.  Why do you care that they didn't come from TSV?
Why should we care if they're actually *real* layer 4 protocols?

-- 
Joe Hildebrand

---

From: Toby Moncaster <[email-masked]>
Date: Thu, 29 May 2014 17:18:52 +0100

I agree that unnecessarily limiting this in the charter seems wrong which is why I suggested the wording change.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 18:30:45 +0200

Well, my concern is about document length. The usefulness of a 200-pager is limited because somehow this complexity is the problem that we want to address here...  but yes, perhaps one needs to have the full beast laid out first, no matter how long it gets. The usefulness is also limited if we make it short but exclude these things, and then have folks coming and saying "but RTP offers this".

So, I agree. But the fun factor of this work has just been reduced  :-)

---

From: Toby Moncaster <[email-masked]>
Date: Thu, 29 May 2014 17:34:41 +0100

My idea was to not exclude these during charter, but to choose to exclude them or not when it comes to actually producing the document. 

Toby

---

From: Michael Welzl <[email-masked]>
Date: Thu, 29 May 2014 18:36:29 +0200

Fine by me!

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 29 May 2014 16:49:15 +0000

+1.  However, if you choose to exclude good ideas, I imagine that will
come up during last call, so I recommend going into the project with the
idea that it's not going to be fun.

On 5/29/14, 10:34 AM, "Toby Moncaster" <[email-masked]> wrote:

>My idea was to not exclude these during charter, but to choose to exclude
>them or not when it comes to actually producing the document.
>
>Toby
>
>> Well, my concern is about document length. The usefulness of a
>>200-pager is limited because somehow this complexity is the problem that
>>we want to address here...  but yes, perhaps one needs to have the full
>>beast laid out first, no matter how long it gets. The usefulness is also
>>limited if we make it short but exclude these things, and then have
>>folks coming and saying "but RTP offers this".
>> 
>>> I agree that unnecessarily limiting this in the charter seems wrong
>>>which is why I suggested the wording change.
>>> 

-- 
Joe Hildebrand

---

From: Aaron Falk <[email-masked]>
Date: Thu, 29 May 2014 14:26:36 -0400

> The Working Group will:

       • specify a set of transport services that end systems need to
> provide and provide guidance on choosing among available mechanisms and

"that end systems need to provide" sounds like this group is adding a MUST
to transport protocol stacks.  Is that really the intent?  Sounds like a
big step.  And not strictly necessary.  Suggest changing "need to" to "may".

--aaron

---

From: Gorry <[email-masked]>
Date: Thu, 29 May 2014 19:56:46 +0100

I wrote this word - I really do not mind, if they implement taps they provide this, I.e. Need - if they choose to do nothing then they won't provide so they "may" implement taps. I hope everyone will do taps - and it will be great -  but that needs to be proven.

I don't care if it says "May" (or "need to provide to implement the framework").

gorry

Sent from my iPad

> On 29 May 2014, at 19:26, Aaron Falk <[email-masked]> wrote:
> 
> "that end systems need to provide" sounds like this group is adding a MUST to transport protocol stacks.  Is that really the intent?  Sounds like a big step.  And not strictly necessary.  Suggest changing "need to" to "may".
> 
> --aaron

---

From: Aaron Falk <[email-masked]>
Date: Thu, 29 May 2014 15:01:08 -0400

Thanks, Gorry.  That clarifies.  I'd suggest "specify a set of transport
services that end systems implementing TAPS need to provide".

--aaron

On Thu, May 29, 2014 at 2:56 PM, Gorry <[email-masked]> wrote:

> I wrote this word - I really do not mind, if they implement taps they
> provide this, I.e. Need - if they choose to do nothing then they won't
> provide so they "may" implement taps. I hope everyone will do taps - and it
> will be great -  but that needs to be proven.
>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 29 May 2014 18:13:48 -0500

> Since I don't think I'm the right person to decide whether the IAB should be mentioned or not I'll see what happens on the list upon Gorry's response before incorporating text on that.

I believe Spencer was encouraging Brian (and it turns out I was using 
"Brian" as a multicast address that also resolves to "Joe", and any 
other IAB members who are listening) to tell us if the IAB is likely to 
have a revised program that we could usefully refer to in the charter 
any time soon.

Unless the answer is some variant of "the IAB just approved a relevant 
program", it's fine to leave the IAB unmentioned.

Thanks,

Spencer

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 30 May 2014 16:00:22 +0000

>have a revised program that we could usefully refer to in the charter

Brian is offline for a couple of days.

>program", it's fine to leave the IAB unmentioned.

We've got some emerging consensus on the IAB on what the relevant program
will be, but are not quite ready to announce it yet.  I suggest leaving a
placeholder that we'll fill in as the process progresses.

-- 
Joe Hildebrand