Subject: [Taps] WG Review: Transport Services (taps)

From: The IESG <[email-masked]>
Date: Fri, 18 Jul 2014 05:14:08 -0700

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-masked]>

Mailing list
  Address: [email-masked]
  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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 18 Jul 2014 13:36:43 +0100

On 18/07/2014 13:14, The IESG wrote:
> can accept blocks of data out of order,
Is that the biggest advantage of SCTP? Surely its multichannel
nature and ability to trade the degree of reliability on a per
channel basis  is more significant?
> and LEDBAT provides
They also loose the ability to take advantage of ECMP
support in the network which is only implemented for
UDP and TCP.
> available on the end points and along the path in the network.
There needs to be some discussion about the overlap with
SFC.
>    reliability, and latency vs throughput, but is not prohibited
I think you need ECMP in there. I think you also need to consider
that a service may require a spectrum. As a example in IPFIX we
needed both a reliable channel for passing the template and a
low overhead channel to pass the data.

You probably need to widen the scope to ensure that you cover
network layer - transport layer interaction.

Is foo over MPLS in or out of scope? Or is this really just TCP/UDP
over IP focussed?
> aspects of transport protocols,
This is concerning since this is a service parameter.

> but TAPS is being chartered
Well, what about the other transport protocols?

You surely need to consider the extent to which metadata in transport
is the key used in flow observation and hence conflicts with the
goals of perpass? You also need to consider that one might want
to do exactly the opposite and enhance observation within
some types of network, perhaps selectively.

What if the transport service requirement were maximal privacy?

Stewart

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

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 18 Jul 2014 15:02:36 +0100

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:

>   Spencer Dawkins <[email-masked] <javascript:;>>
>
> Mailing list
>   Address: [email-masked] <javascript:;>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 18 Jul 2014 10:44:27 -0700

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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 18 Jul 2014 11:15:03 -0700

Some more points:

The text does not state if/how the WG will take the impact of known
unavoidable network path issues (NAT/FW/Proxy) and known application domain
architectures (eg: browser as middleware, "web" centric applications) into
account.  IMHO, TAPS must not create ivory tower analysis that ignore these
aspect or create recommendations / directions incompatible with them,
and this should be in the charter.

I can not understand how QoS can be outside the scope of the WG when
a lot of transport protocol services differences are exactly about that. 
What other than QoS mechanisms are the congestion control mechanisms
mentioned upfront ? LEDBAT is a transport for a specific QoS experience.
Is TAPS planning to ignore all protocol/queuing differences in transport
meant to deal with QoS ? Why ?

I am positively surprised though to see that IP multicast  transport
is in charter given the IAB/IESG policy that every new WG too lazy
to consider IP multicast must also explicitly rant in its charter about
t being unnecessary and complex and therefore excluded from the charter. 

( I thought in face of the BCP 56 paragraph i could also put
  something into the mouth of IETF bodies - especially because i actually
  did hear that position expressed repeatedly in public by members of
  those bodies ;-P ).

Cheers
    Toerless

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 19 Jul 2014 14:51:43 -0400

Hi, Toerless,

The TAPSters are scurrying madly in preparation for the TAPS BOF on 
Monday, and I'm expecting them to review all IETF WG Review comments 
made up to that point (keeping in mind that the date on the request for 
comments is 7-31, to allow more people to provide input), but I should 
reply to this part of your review comments.

> it is wrong and inflammatory.

You could be right :p

Most of the TAPS charter that's up for review now was pretty carefully 
written and discussed on the TAPS mailing list, but the BCP 56 reference 
was not. I wrote it.

> at fault.  Ultimately, 90% of that BCP are about other problems than the

I scribbled something quickly in response to internal review comments 
about the previous version of the charter focusing on IETF transport 
protocols.

What I intended to say was that while the IESG didn't come out with a 
ringing endorsement of HTTP as a transport substrate when they produced 
BCP56, the working group charter being approved in 2014 should allow the 
working group to think about HTTP, in addition to the usual TCP, UDP, etc.

If that's not what people read, that's my fault.

> I can not believe that WebSockets is seen as a bad but unavoidable

It was not my intention to say anything about WebSockets, and if I 
managed to accomplish that without trying, that's my fault.

It's also worth mentioning that I'm hoping to have one co-chair with 
significant APP or RAI background, if I can identify the right person, 
so the perspective you shared in your final paragraph should not fall on 
deaf ears.

And thank you for providing WG Review comments.

Spencer

---

From: Brian Trammell <[email-masked]>
Date: Sat, 19 Jul 2014 15:42:05 -0400

hi Spencer, Toerless, 

>> BCP 56 problems than that negatives of BCP 56 apply to it.

Absolutely. However, it's constrained to run atop TCP, which means that as an application you have no control over the _transport_ characteristics of a WebSockets connection. You get SOCK_STREAM, end of discussion, with whatever global parameters your kernel has decided are good for you.

That's the situation we're looking to improve.

And +1 to "thanks, Toerless, for the comments". Hope to see you at the charter discussion on Monday.

Cheers,

Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 21 Jul 2014 20:03:32 -0700

> Absolutely. However, it's constrained to run atop TCP, which means that as an application you have no control over the _transport_ characteristics of a WebSockets connection. You get SOCK_STREAM, e…

Sure. But BCP56 does not address anything here. If i just build a protocol
on top of TCP without any HTTP, BCP56 will be fine with me.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 22 Jul 2014 12:28:00 -0400

based on the discussion yesterday I think this charter if not clear enough

it seems that it would be good to say specifically that the goal is define 
a API that lets a application tell the kernel what the characteristics it would like 
to get in a connection so that the kernel can poke around and see what transports 
are available for that connection and to pick the one that best meets the characteristics
to run the connection over

assuming that is actually what the goal is (I got that in talking with the BOF chair after the BOF) 
then it would be good to make things as clear as possible

Scott