Let me comment in this email on the paragraph about BCP 56, i think
it is wrong and inflammatory.
The paragraph first badmouths programmers stating they "simply give up",
without producing any evidence that the programmers in question could
actually have done something effective: What programmer has given up on what ?
Eg: Javascript developers have given up on writing network protocol stack
for widely deployed proprietary desktop/mobile OS from three vendors ????
When the paragraph then says ... it is assuming "...." ..., it is putting
words into the BCPs mouth that are not in evidence in that BCP. Then that
assumption is singling out one aspect of the BCP, that firewalls/proxies are
likely to pass HTTP/port 80 when other traffic is blocked, and make it
sound as if that is then the reason, why there are "many issues with this
strategy".
In fact, that aspect is just half a page in the BCP, and not even
a particularily good half page because it is not speaking out positively
about the accused in the face issues where really the network path is
at fault. Ultimately, 90% of that BCP are about other problems than the
network path.
And then this TAPS paragraph claims that the IESG has expressed
the paragraphs view (blaming programmers, making BCP 56 primarily about FW
bypass, etc..), and has called out the negatives of BCP 56 against
WebSockets. I do not know what the IESG has really said (the paragraph
provides no reference), but BCP 56 predates WebSockets by many years
AFAIK, and 90% of that BCP are not applicable to WebSockets.
I can not blieve that WebSockets is seen as a bad but unavoidable
protocol approach. I rather think a lot of APP area folks in the IETF
would state exactly the opposite: It is a pretty good coalescion of
higher layer needed functionality (during conn setup), fits snugly into
the web centric app layer framework (browsers, http), and manages to minimize
messy network layer midpoint problems (eg: flow state problems in midpoints).
And WebSocket effectively is also meant to kill a lot of the protocols
that where really badly built on top of HTTP, aka: it solves a lot more
BCP 56 problems than that negatives of BCP 56 apply to it.
Cheers
Toerless
On Fri, Jul 18, 2014 at 05:14:08AM -0700, 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 <spencerdawkins.ietf@xxxxxxxxx>
>
> Mailing list
> Address: taps@xxxxxxxx
> 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