I did not understand the charter, it is general transporting, maybe designing new transports. The WG should consider defining application use cases and the needed services requirements. I recommend this WG looks into engaging transports for the LLN services, MANET services, IoT services, and ITS services.
AB On Friday, July 18, 2014, The IESG wrote: > A new IETF working group has been proposed in the Transport Area. The > IESG has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-31. > > Transport Services (taps) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > TBD > > Assigned Area Director: > Spencer Dawkins <[email protected] <javascript:;>> > > Mailing list > Address: [email protected] <javascript:;> > To Subscribe: https://www.ietf.org/mailman/listinfo/taps > Archive: http://www.ietf.org/mail-archive/web/taps/ > > Charter: > > In the TAPS charter, the term "Transport Service" means any > service provided by the transport layer that can only be > correctly implemented with information from the application. > > The vast majority of Internet applications make use of the > Transport Services provided by TCP (a reliable, in-order > stream protocol) or UDP (an unreliable datagram protocol). > > Other transport protocols such as SCTP, DCCP, MPTCP, > 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 that > can accept blocks of data out of order, and LEDBAT provides > low-priority "scavenger" communication. > > Application programmers face difficulty when they use protocols > other than TCP or UDP. Most network stacks only support TCP > and UDP, and many firewalls only pass TCP and UDP, so using > other transport protocols risks having an application not > work in many environments. Applications, therefore, must > always be able to fall back to TCP or UDP, and once the > application programmer has committed to making an application > work on TCP or UDP, 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 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 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 TCP would > have avoided, and ensure that the applications can't > benefit from other transport protocols as they become > available. > > Alternatively, programmers may simply give up on using > transport protocols direcly, 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 Websockets protocol > on the standards track. > > The Working Group deliverables will help an application > programmers identify the important Transport Services for > applications and determine if those Transport Services are > available on the end points and along the path in the network. > 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: > > - Identify Transport Services provided by existing IETF > protocols and congestion control mechanisms. The resulting > document will provide guidance on making a choice among > available mechanisms and protocols to obtain a certain > Transport Service. As a starting point, the working group will > consider: ordering/sequence preservation, degree of > reliability, and latency vs throughput, but is not prohibited > from considering others. > > - 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. > > - Specify experimental mechanisms to provide a given Transport > Service. This document will explain how to select and engage > an appropriate protocol and how to discover which protocols > are available for a given connection. Futher, it will provide > a basis for incremental deployment. > > The following topics are out of scope for this Working Group: > > - Quality-of-Service (QoS) and tunneling mechanisms and services > > - Definition of new encapsulations and tunneling mechanisms > > - Extension or modification of transport protocols > > - Language-specific APIs > > TAPS is not chartered to perform detailed analysis of the security > aspects of transport protocols, but 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: > > M9: Submit summary of the services provided by IETF transport > protocols and congestion control mechanisms to IESG. > M15: Submit end system transport services to IESG. > M18: Submit specification of how the transport services can be > provided to IESG. > > Milestones: > > TBD > >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
