Congratulations dragana
On Wed, Sep 24, 2014 at 12:47 PM, Marie-Jose Montpetit <mari...@mit.edu> wrote: > Congratulations! > > Marie-José Montpetit > mari...@mit.edu > > > On Sep 24, 2014, at 05:59, Michael Welzl <mich...@ifi.uio.no> wrote: > > > > Hooray! Thanks everyone for your efforts!! > > > > > >> On 24. sep. 2014, at 01:33, The IESG wrote: > >> > >> A new IETF working group has been formed in the Transport Area. For > >> additional information please contact the Area Directors or the WG > Chair. > >> > >> Transport Services (taps) > >> ------------------------------------------------ > >> Current Status: Proposed WG > >> > >> Chairs: > >> Aaron Falk <aaron.f...@gmail.com> > >> > >> Assigned Area Director: > >> Spencer Dawkins <spencerdawkins.i...@gmail.com> > >> > >> Mailing list > >> Address: taps@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/taps > >> Archive: http://www.ietf.org/mail-archive/web/taps/ > >> > >> Charter: > >> > >> Most Internet applications make use of the Transport Services > >> provided by TCP (a reliable, in-order stream protocol) or UDP > >> (an unreliable datagram protocol). We use the term "Transport > >> Service" to mean an end-to-end facility provided by the > >> transport layer. That service can only be provided correctly if > >> information is supplied from the application. The application may > >> determine the information to be supplied at design time, > >> compile time, or run time and may include guidance on whether > >> the facility in question is required or simply a preference by the > >> application. Four examples of Transport Services are reliable > >> delivery, ordered delivery of data, content privacy to in-path > >> devices, and minimal latency. > >> > >> Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and > >> UDP-Lite and the LEDBAT congestion control mechanism extend the > >> set of available Transport Services beyond those provided to > >> applications by TCP and UDP. For example, SCTP provides potentially > >> faster reliable delivery for applications than TCP because it can > >> accept blocks of data out of order, and LEDBAT provides low-priority > >> "scavenger" communication. > >> > >> However, application programmers face difficulty when they use > >> protocols other than TCP or UDP. Most network stacks ship with only > >> TCP and UDP as transport protocols. Many firewalls only pass TCP > >> and UDP and some only allow TCP when it carries HTTP as its payload. > >> As a result, using other transport protocols or building a new protocol > >> over raw sockets risks having an application not work in many > >> environments. Applications, therefore, must always be able to fall back > >> to TCP or UDP, or even to using HTTP as a transport substrate in some > >> cases, and once the application programmer has committed > >> to making an application work on TCP or UDP or HTTP, there is little > >> incentive to try other transport protocols before falling back. > >> Further, different protocols can provide the same services in different > >> ways. Layering decisions must also be made (for example, whether a > >> protocol is used natively or tunneled through UDP). > >> > >> Because of these complications, programmers often resort to either > >> using TCP or HTTP or implementing their own customized "transport > >> services" over UDP. When application developers re-implement transport > >> features already available elsewhere they open the door to problems > >> that simply using TCP would have avoided and ensure that the > >> applications can't benefit from other transport protocols as they > >> become available. And, since even TCP and UDP are not guaranteed to > >> work in all environments today, some programmers simply give up on > >> using TCP or UDP directly, relying instead on "HTTP as a Substrate". > >> BCP 56 identified many issues with this strategy, but assuming that > >> if "any protocol is available on a given network path and on the hosts > >> that will be communicating, that protocol will be HTTP" is a reasonable > >> strategy for today's Internet. The IESG has agreed with this viewpoint > >> enough to publish the WebSocket protocol on the standards track. > >> > >> The goal of the TAPS working group is to help application and network > >> stack programmers by describing an (abstract) interface for applications > >> to make use of Transport Services. The Working Group deliverables > >> emphasize defining Transport Services that are important to applications > >> followed by experimental mechanisms to a) determine if the protocols to > >> provide the requested services are available on the end points and > >> supported along the path in the network and b) fall back, i.e., select > >> alternate, possibly less-preferred, protocols when desired protocols > >> are not available. The Working Group will not define a richer set of > >> Transport Services for applications, although the TAPS deliverables > >> could inform proposals for future chartered work on Transport Services. > >> > >> The Working Group will: > >> > >> 1) Define a set of Transport Services, identifying the > >> services provided by existing IETF protocols and congestion > >> control mechanisms. As a starting point, the working group will > >> consider services used > >> between two endpoints. > >> > >> 2) Specify the subset of those Transport Services, as identified > >> in item 1, that end systems supporting TAPS will provide, and > >> give guidance on choosing among available mechanisms and > >> protocols. Note that not all the capabilities of IETF Transport > >> protocols need to be exposed as Transport Services. > >> > >> 3) Specify experimental support mechanisms to provide the Transport > >> Services identified in work item 2. This document will explain > >> how to select and engage an appropriate protocol and how to > >> discover which protocols are available for the selected service > >> between a given pair of end points. Further, it will provide a > >> basis for incremental deployment. Work on this document will > >> begin when the TAPS Transport Services have been specified. > >> > >> The following topics are out of scope for this Working Group: > >> > >> - Signaling-based Quality-of-Service (QoS) mechanisms > >> > >> - Definition of new encapsulations and tunneling mechanisms > >> > >> - Extension, modification, or creation of transport protocols > >> > >> - Language-specific APIs > >> > >> TAPS is not chartered to perform detailed analysis of the security > >> aspects of transport protocols. While security can be a transport > >> service, TAPS is being chartered almost simultaneously with TCPINC, > >> which is developing the TCP extensions to provide unauthenticated > >> encryption and integrity protection of TCP streams, and TAPS will > >> work with TCPINC to ensure that TAPS will be able to accommodate > >> the protocol extensions that TCPINC defines. > >> > >> Milestones: > >> Jun 2015 - Submit an Informational document to the IESG defining a set > >> of services provided by IETF transport protocols and congestion control > >> mechanisms > >> Dec 2015 - Submit an Informational document to the IESG recommending a > >> minimal set of Transport Services that end systems should support > >> Mar 2016 - Submit an Experimental document to the IESG specifying one > >> or more methods to provide applications with the Transport Services > >> identified by the WG > >> Mar 2016 - Recharter or conclude. > >> > >> > >> _______________________________________________ > >> Taps mailing list > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
